Hallo zusammen
Ich hoffe, das ich mit meinem ersten post im richtigen Forum gelandet bin.
Als neues Mitglied hier im Forum, möchte ich mein Vorhaben kurz vorstellen, bevor ich mein aktuelles Problem beschreibe. Ich bin vor ein paar Wochen über fhem gestolpert, während ich nach einer Möglichkeit gesucht habe, meine Rollläden im Obergeschoss des Hauses automatisch zu steuern. Dabei soll der Rollladen im Schlafzimmer nach einem drei Wochen Schema arbeiten, weil ich in drei Schichten arbeite. Bei meiner Heizung funktioniert das schon mittels Fritz Box und Google Kalender.
Dazu habe ich nun einen Paspberry PI3 gekauft und Raspbian Jessie darauf installiert. Fhem ist auch schon installiert und läuft auch. Ich kann vom PC aus darauf zugreifen. Ebenso funktioniert der Zugriff auf Raspbian mittels putty.
Da ich schon einige Funksteckdosen und eine Markisensteuerung von Intertechno besitze, sollten diese Komponenten ebenso durch fhem angesprochen werden können, wie auch schon vorhandene Heizkörper Stellantriebe der FS20 Baureihe von Conrad. Welche Aktoren letztendlich die Rollläden ansteuern ist zurzeit noch offen.
Darum möchte ich auf dem Raspberry zwei CC101 Transreceiver stapeln. Einen mit 433Mhz mit Drahtantenne für die Intertechno Komponenten und einen mit 868Mhz mit RP-SMA Antenne für die FS20 Komponenten.
Hier ist zurzeit auch mein Problem. Ich will den 433Mhz Transreceiver in fhem einbinden, bekomme aber immer die Meldung: SCC disconnectet. Alle Beschreibungen, die sich auf das Einbinden beziehen, scheinen sich auf das 868Mhz Modell zu beziehen und auch auf ältere Raspbian Versionen. Ich weiß auch nicht, ob ich die richtige Firmware auf dem Transreceiver habe. Angeblich soll sie aber drauf sein. Das könnte ich in fhem ja überprüfen und auch ändern. Dazu muss das Gerät aber eingebunden sein, oder? Hier stehe ich also gerade auf dem Schlauch.
Die Ausgangssituation ist zurzeit folgende: Das Modul steckt alleine auf dem Raspberry und die LED blinkt. Wie sollte es nun weiter gehen? Welche Infos benötigt ihr, um mir ein wenig auf die Sprünge zu helfen?
Vielen Dank schon mal
edition
Hallo,
hilfreich wäre schon mal folgendes:
welches Funkmodul hast du bzw. nach welcher Anleitung (wenn "Eigenbau") bist du vorgegangen.
Da du stapelst, hängt das Funkmodul direkt an den GPIO des PI (nehme ich jetzt mal an)!?
Wie sieht der "define" des Funkmoduls in fhem aus.
Evtl. mal verbose (wenn noch nicht viel läuft, dann einfach beim "Modul" global / ansonsten beim "Funkmodul") auf 5 setzen und mal den entsprechenden Auszug aus der Logdatei posten.
Anschließend wieder verbos zurück (auf 3) setzen, sonst läuft das Log voll...
Die genannten Infos, Logauszüge etc. am besten in "code-Tags" setzen, das ist in der Icon-Leiste oben das '#'...
Gruß, Joachim
Hallo
Danke erst mal, das sich jemand meiner annimt.
Ich verwende Funkmodule von Busware. Das 433MHz Modul ist schon da, auf das andere warte ich noch. Beide sollen direkt am GPIO des Raspberry betrieben werden. Den Anfang wollte ich mit dem vorhandenen Modul machen und das andere dan installieren, wenn es da ist.
Das "define" habe ich von der Busware Seite übernommen: define SCC CUL /dev/ttyS0@38400 1234
Dadurch wird aber dann als CUL ein SSC für FS20 etc. erzeugt (was ich ja nicht haben wollte) und welches außerdem "disconnected" ist.
Im Log taucht folgendes auf:
2016.05.24 10:43:57 3: Opening SCC device /dev/ttyS0
2016.05.24 10:43:57 3: Can't open /dev/ttyS0: Datei oder Verzeichnis nicht gefunden
Und da komme ich nicht richtig weiter. ttyS0 müsste doch die Schnittstelle sein, die doch aber offen ist. Das Modul blinkt ja. Oder habe ich da einen Denkfehler? Das fehlende Verzeichniss, bzw. die Datei verwirrt mich dabei. Im Verzeichniss dev sind jede Menge Dateien mit tty. Das geht von tty0 bis tty63 und ttyAM. Warum wird dann auf ttyS0 verwiesen? Muß ich das noch installieren, oder auf eine andere Datei verweisen?
Fragen über Fragen.
Hallo,
das hilft schon mal weiter.
Also entweder wird der CUL nicht erkannt (wobei ich zugeben muss, dass ich bislang ausschliesslich USB verwende) oder unter einer anderen Schnittstelle.
Oder die Fehlermeldung ist nicht ganz stimmig und es ist nicht möglich die Schnittstelle zu öffnen (z.B. fehlende Berechtigung, allerdings sollte dann eher sowas wie access denied kommen).
Alles was unter /dev zu finden ist sind "Anschlüsse" bzw. "Devices".
Z.B. serielle Schnittstelle, USB-Devices etc.
Und in Linux ist so ziemlich alles eine Datei, also auch Ein-/Ausgabegeräte wie dein CUL...
Und in /dev musst/kannst du nichts installieren.
Irgendwie sieht es so aus als ob dein CUL unter einer anderen Schnittstelle angelegt wurde.
Denn wie ich dich verstehe ist in /dev kein ttyS0 zu finden!?
Wie gesagt ich kenne die stackable CUL zu wenig aber vielleicht hilft mal ein ls /dev/tty* mit und ohne gestecktem CUL zu vergleichen.
Evtl. kommst du so auf die "Bezeichnung" unter der dein CUL zu finden ist...
Achja du hast schon ttySNull eingegeben, nicht dass du den Buchstaben 'O' genommen hast...
Gruß, Joachim
Hab auch nur die USB-CULs,
ZitatDas geht von tty0 bis tty63 und ttyAM. Warum wird dann auf ttyS0 verwiesen?
Dann wurde der SCC wohl nicht erkannt :( aber lt. busware-Anleitung sind auch noch weitere Schritte zur Installation erforderlich. Hast Du die gemacht ?
Mit
dmesg | grep -i tty siehst Du ein wenig mehr zu Deinen Schnittstellen, was vielleicht weiterhelfen könnte.
Grüße, Markus
Du kannst auch mal im "kern.log" suchen
grep /var/log/kern.log -i tty
Eventuell könnte er auch dupliziert per Seriennummer eingerichtet worden sein, kann mich da aber täuschen. Gib uns doch mal den Output von
find /dev/serial/
Hallo
Ich habe es einmal mit:
define SCC CUL /dev/tty0@38400 1234
versucht, also ohne S. Die Datei ist ja unter /dev vorhanden.
Das Ergebnis ist das selbe, aber die Meldung im Log file sieht jetzt so aus:
2016.05.25 08:50:39 3: Opening SCC device /dev/tty0
2016.05.25 08:50:39 3: Can't open /dev/tty0: Keine Berechtigung
Nachdem Markus darauf hingewiesen hat, ob ich die weiteren Schritte zur Installation ausgeführt habe, ahne ich böses.
Bei allen Suchanfragen habe ich immer CUL eingegeben. Kann es sein, das ich dabei immer nur Anleitungen für die USB Variante finde und mein Raspberry nun "falsch" vorbereitet ist?
Die Ausgabe auf:
dmesg | grep -i tty
fördert folgendes zu Tage:
[ 0.000000] Kernel command line: 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_
fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082 bcm2709.serial=
0x23a8534d smsc95xx.macaddr=B8:27:EB:A8:53:4D bcm2708_fb.fbswap=1 bcm2709.uart_c
lock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm
_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline roo
twait
[ 0.001337] console [tty1] enabled
[ 2.120638] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud =
0) is a PL011 rev2
Ich sehe hier ttyAMA0. Das finde ich auch bei der Einrichtung eines USB CUL.
Ist hier der Fehler?
Gruß
also ... ein tty? mit einer "?" als reinen Nummer bekommst Du keine Serielle Konsole sondern eine reine Konsole, d.h. ein "Eingabe-Konsole", sprich Terminal.
ttyAMA0 dagegen hört (und sieht) sich gut an. Damit schon probiert?
Ja, so funktioniert was. Aber:
2016.05.25 10:45:22 3: Opening SCC device /dev/ttyAMA0
2016.05.25 10:45:22 3: Setting SCC serial parameters to 38400,8,N,1
2016.05.25 10:45:22 3: SCC device opened
2016.05.25 10:45:31 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Da habe ich auch schon was gefunden: https://forum.fhem.de/index.php/topic,50340.0.html (https://forum.fhem.de/index.php/topic,50340.0.html)
Das probiere ich heute Abend, wenn ich von der Arbeit zurück bin.
Hm, das war wohl nix. Und nun?
Hat jemand eine Idee?
Gruß
edition
Hi,
Ich selbst nutze auch nur USB Selbstbau CULs.
Aber ich habe ein paar Gedanken zu Deinem Aufbau:
Erstens habe ich hier eine zugegeben kurze Anleitung gefunden:
http://busware.de/tiki-index.php?page=SCC_Installation
Zweitens ist es ja so, dass der Raspberry auf der Schnittstelle /dev/ttyAMA0 beim Standard Raspbian Download schon etwas anderes installiert hat. Sprich in der Datei /boot/cmdline.txt wird eine Eingabekonsole auf diese serielle Schnittstelle gelegt. Das hat den Hintergrund, dass man auch ohne Netzwerkzugang - mit einem anderen Computer über eine serielle Schnittstelle an den GPIO Pins angeschlossen - dem Raspberry Befehle wie mit Tastatur zusenden kann. Zum Basteln und Debuggen ist das super! Für Deinen Zweck aber falsch, da der CUL den gleichen Eingang benutzt. Aber eben nur ein Programm/Anwendungsfall gleichzeitig aus der Schnittstelle lesen kann.
Drittens wird auch in der /etc/inittab diese Verknüpfung gesetzt, daher muss auch hier der getty Eintrag für ttyAMA0 auskommentiert werden.
Viertens hat der Raspberry 3 auch noch Bluetooth an Board. Hier im Forum hatte ich irgendwo gelesen, dass auch diese Kommunikation über ttyAMA0 läuft. Kann also sein, dass hier auch noch etwas deaktiviert werden muss.
Generell: Zum Bearbeiten von Dateien unter Linux nutze ich "sudo nano <Datei>". Auskommentieren einer Zeile passiert, indem als erstes Zeichen in der Zeile ein # eingefügt wird.
Ich hoffe Dur hilft das jetzt weiter ;-)
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Hallo
Die Busware Anleitung kenne ich. Darum hatte ich es ja auch mit:
define SCC CUL /dev/ttyS0@38400 1234
versucht. Das soll ja für PI3 sein.
Auch, das ich in der Datei /etc/inittab etwas löschen muss, weiß ich. Allerdings ist die Datei bei Raspbian Jessie nicht vorhanden.
Ich befürchte, das ich durch zu viel rumprobieren vielleicht schon etwas falsches installiert, oder gelöscht habe. Alle Anleitungen beziehen sich meistens auf Raspberry PI in Verbindung mit Raspbian wheezy, oder noch älter. Beim PI3 und Jessie ist doch einiges anders. Ich denke, ich fange noch mal von vorne an. Dann kann ich wenigstens ausschließen, das im Vorfeld schon etwas schief gelaufen ist.
Ich warte wohl auch besser erst, bis das 868MHz SCC da ist. Dann kann ich auch sicherstellen, das auf beiden SCC die richtige Firmware drauf ist.
Wenn ich die fhem.cfg sichere und später zurückspiele, sollte in fhem alles wieder so sein, wie es jetzt ist, oder?
Gruß
edition
ich denke Du solltest alles vergessen, was sich auf Rpi < 3 und USB bezieht. Auch ttyAMA0 !
Konzentrier Dich auf meinen obigen Link ins Wiki. Der Autor wird sich etas dabei gedacht haben !!! SCC und GPIOs sind Dein Problem. Ich wette, dass Du dann mit den Linux-commands auf das ttyS0 stößt.
Nicht verzagen, Markus
Hi
Hab gersde mal die Gegenprobe gemacht und Raspbian Jessie auf einer frischen SD Karte installiert. Nach dem ersten Start ist ttyS0 im dev Verzeichniss vorhanden. Nachdem ich update und upgrade durchgeführt habe, nicht mehr. Was ist das denn nun?
und das
ZitatYou need to free-up the serial line used by SCC. Remove any references to ttyAMA0 in:
• /etc/inittab - comment or delete: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
• /boot/cmdline.txt - and reboot!
By default the radio is held in RESET which is connected to GPIO17. You need explicitly pull GPIO17 HIGH to un-reset the radio:
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
By doing this the LED@SCC should start blinking.
hast Du gemacht ? Also beide Dateien editiert, GPIO17 auf High gesetzt ? Blinkt die LED ?
Ich denke, dass das SCC immer noch im Reset-Modus ist :'(
Markus
Hi
Also noch mal langsam.
Laut Busware soll ich beim PI 3 das SCC mit folgendem Befehl einbinden:
define SCC CUL /dev/ttyS0@38400 1234
Das hat nicht funktioniert, weil unter /dev kein ttyS0 vorhanden ist. Jetzt habe ich also eine neue SD Karte genommen und Raspbian Jessie darauf installiert. Die Karte in den Rspberry gesteckt und gestartet. Nach dem Start alles auf deutsch gestellt, WLAN eingerichtet und neu gestartet. Dann habe ich unter /dev nachgesehen, ob ttys0 vorhanden ist. Es war da. Dann habe ich update ausgefüht, neugestartet und wieder nachgesehen. ttyS0 ist immer noch vorhanden. Dann habe ich upgrade ausgeführt, neugestartet und wieder nachgesehen. Jetzt ist ttyS0 weg!
Die Datei /etc/initab ist unter Jessie nicht vorhanden. Da kann ich also nix löschen. Warum werde ich also darauf hingewiesen?
Die Datei /boot/cmdline.txt ist vorhanden. Auch da steht nix von ttyAMA0. Da kann ich also auch nix löschen. Den "if test !.... Text habe ich in /boot/cmdline.txt eingefügt.
Nach einem Neustart blinkt jetzt die LED auf dem Transreceiver. Wenn ich nun unter fhem
define SCC CUL /dev/ttyS0@38400 1234
eingebe und Enter drücke, stürzt die Anwendug ab!
Was ist jetzt wieder? Ich verzweifel hier langsam.
edition
wird schon werden ;)
jetzt blinkt die LED und Du jetzt hast Du das ttyS0 device ? Was stürzt ab ? FHE,M oder ? Dann schau mal ins Log von fhem, was als letztes passiert ist und bevor Du den fhem-Befehl absetzt nochmal über die geposteten Linux-commands nachsehen, was nun dort angezeigt wird.
Grüße, Markus
Wenn Du ein upgrade machst, WAS wird denn upgegraded? apt-get (oder auch aptitude o.Ä.) sag es Dir ausführlich ....
Hallo
Nur um es noch mal klar zu stellen: Ich arbeite gerade mit eier Art "Testinstallation" auf einer älteren 8GB SD Karte. Ich wollte herausfinden, warum ich auf meiner ursprünglichen Installation unter /dev kein ttyS0 mehr befindet. Das scheit zu verschwinden, wenn ich apt-get upgrade ausführe. Nach apt-get update war es noch vorhanden. Apitude update/upgrade habe ich nicht ausgeführt. ttyS0 ist zur Zeit auch noch vorhanden.
Zwischenzeitlich habe ich mich allerdings durch eine Anleitung führen lassen, die ich hier im Forum gefunden habe, die sich auf PI 3 und Jessie bezieht. Da wird die serielle Schnittstelle abgeschaltet. Dann kommt es zum "einfrieren" von fhem, wenn ich das SCC definiere. Schalte ich die serielle Schnittstelle wieder ein, ist das SCC wieder disconnectet.
Ich werde morgen früh noch mal alles auf Null setzen. Auch will ich sicherstellen, das ich überhaupt eine Firmware auf dem SCC habe. Da bin ich mir nämlich auch nicht so sicher. Da ich damit ja 433MHz Intertechno schalten will, soll ohnehin die dafür optimierte Variante drauf. Hier muss die Verbindung ja auch stimmen. Vielleicht komme ich ja da auf den Fehler.
Gruß
edition
So, ich habe mich nochmal daran gesetzt und bin nun nach dieser Anleitung vorgegangen, die am Ende aufgelistet ist:
https://forum.fhem.de/index.php?topic=47046.0 (https://forum.fhem.de/index.php?topic=47046.0)
Jetzt habe ich das SCC definiert, wie es bei busware beschrieben ist:
define SCC CUL /dev/ttyS0@38400 1234
Unter /dev ist ttyS0 nun auch vorhanden.
Ist aber mal wieder disconnected!
Im Log erscheint:
2016.05.28 12:30:04 3: Opening SCC device /dev/ttyS0
2016.05.28 12:30:04 1: PERL WARNING: can't getattr: Eingabe-/Ausgabefehler at ./FHEM/DevIo.pm line 319.
2016.05.28 12:30:04 3: Can't open /dev/ttyS0: Eingabe-/Ausgabefehler
Also wieder ein neuer Fehler, mit dem ich nix anfangen kann! Toll
Wei sieht denn die Berechtigung von ttyS0 aus, bzw. welche Rechte hat fhem.
Hm, mal sehen, ob ich das überhaupt beantworten kann.
Wenn ich mit Filezilla auf den Raspberry zugreife und ins /dev Verzeichniss wechsel, kann ich sehen, das ttyS0 die Rechte crw-rw----, oder 660 hat. Beim fhem Verzeichniss unter /opt sind die Rechte auf crwxrwxrwx, oder 777 gesetzt und beim darunter liegendem FHEM Verzeichniss auch.
War das die Antwort auf die Frage, oder bin ich gerade schief gewickelt?
Bitte nicht mit Filezilla, sondern direkt per Konsole, d.h. "ls -lha" .. alles andere ist etwas .... vorsichtig zu handeln ...
Wir brauchen nicht nu die direkten Rechte, sondern auch, welcher User/Gruppen die Zugriffe haben.
Und wenn Du wisen willst, was fhem für rechte hat:
grep fhem /etc/passwd
grep fhem /etc/group
OK
Also, wenn ich für das /dev Verzeichniss ls -iha ausführe, steht vor ttyS0 die Zahl 1107.
Bei grep fhem /etc/passwd kommt:
fhem:x:999:20::/opt/fhem:/bin/false
und bei grep fhem /etc/group komt nichts.
Da ist doch was falsch.
Hi,
also der Befehl "ls -la /dev/ttyS*" listet uns die Rechte und die Dateien zur Hardware an. Hier sollte ttyS0 mit der dialout Gruppe und dem user root verknüpft sein (root:dialout).
Falls Sie nicht mit dialout verknüpft ist (root:root), kann fhem nicht darauf zugreifen.
Dann hilft für einen test ein "sudo chown root:dialout /dev/ttyS*".
Danach einmal fhem starten und dort im Log schauen ob das Device geöffnet werden kann.
Übrigens wird bei mir in der /etc/group Datei auch kein user fhem aufgeführt, aber der user pi ist in der gruppe dialout. Der Befehl "groups fhem" zeigt an in welchen Gruppen fhem ist. Der Befehl "groups" analog für den aktuellen Benutzer.
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Besser währe es , vor der Behebung erstmal zu wissen, WAS dort steht.
Kannst Du uns bitte den KOMPLETTEN output geben
ls -la /dev/ttyS*
Und bitte Zusätzlich:
grep 20 /etc/group
Wenn Dein Server Standard Debian, ist 20=dialout, aber besser prüfen.
Aber bitte nicht nur selber prüfen, sondern uns den Output geben. Besser zuviel posten als Zuwenig, denn:
Ohne Input kein Output
OK
auf ls -la /dev/ttyS* folgt:
crw-rw---- 1 root dialout 4, 64 Mai 28 17:02 /dev/ttyS0
und auf grep 20 /etc/group folgt:
dialout:x:20:pi
Sieht richtig aus, oder? Mehr kommt nicht.
Rechtemäßig sieht es gut aus .. aber
2016.05.28 12:30:04 1: PERL WARNING: can't getattr: Eingabe-/Ausgabefehler at ./FHEM/DevIo.pm line 319.
2016.05.28 12:30:04 3: Can't open /dev/ttyS0: Eingabe-/Ausgabefehler
Da muß ein Modulspezialist ran, ich kann es nicht ...
Hm, schade.
Aber trotzdem Danke!
Nur mal für die Fehlersuche, bei einem "echten" CUL muss bei folgendem ein Feedback kommen:
1) schalte fhem ab und kontrolliere, das es nicht "an" ist
ps aux | grep [f]hem
2) Mache 2! Konnektion (Terminal-Fenster) zum RasPI auf
3) bei folgenden den /dev/tty..... durch Deinen ersetzen
3a) Lese dauerhaft deinen CUL aus
tail -f /dev/tty.....
3b) Im 2. Fenster frage Deinen CUL nach der Version
echo "v" >/dev/tty....
4) im Fenster von 3a) soll eine Ausgabe erscheinen ...
z.B. bei mir (ist aber ein USB-Gerät)
[pcaSerial.10.1]
Available commands:
..,.. s - send data packet
l - list devices
<n> a - turn activity LED on PB1 on or off
<n> c - config (0=fill, 1=load, 2=save, 3=erase)
<n> d - turn off device <n>
<n> e - turn on device <n>
0x<hhhh> h - set center frequency (Example 0xA6FE == Frequency - 868.9500MHz
<n> p - poll device <n>
<n> r - list recordings
<n> q - quiet mode (1=suppress TX and bad packets)
<n> v - version and configuration report
OK 24 1 4 6 200 148 0 0 0 0 0
OK 24 4 4 2 116 172 1 0 237 2 85
OK 24 2 4 13 60 22 1 5 152 1 0
Wenn das Kommt, hat Dein FHEM ein Problem. Wenn es NICHT kommt, Dein CUL ....
P.S: Bitte mit passenden Berechtigungen, hier also bitte als root
Wollen wir mal sehen.
Ich stoppe fhem mit:
/etc/init.d/fhem stop
Ich prüfe, ob es auch wirklich gestopt ist:
sudo ps aux | grep [f]hem
Ich lande ohne Ausgabe wieder am promt.
Ich gebe ein:
sudo tail -f /dev/ttyS0
und erhalte folgende Meldung
tail: Fehler beim Lesen von ,,/dev/ttyS0": Eingabe-/Ausgabefehler
tail: auf ,,,,/dev/ttyS0"" kann jetzt zugegriffen werden
tail: /dev/ttyS0: es ist nicht möglich, zum Offset 0 zu springen: Nicht erlaubter Seek
In einer 2. Sitzung gebe ich ein:
sudo echo "v" >/dev/ttyS0
Und es kommt:
echo: Schreibfehler: Eingabe-/Ausgabefehler
Das sieht nicht gut aus.
Ich werde mal die Test sd aus dem Raspi nehmen und die Urinstallation einsetzen. Da mache ich dann das gleiche. Mal sehn, was da passiert.
Na das war ja eine tolle Idee. Auf meiner Urinstallation war ja die ttyS0 nicht mehr vorhanden. Da ich eh nicht mehr wusste, was ich da so alles installiert hatte, habe ich auch hier noch mal von vorne angefangen.
Ich bin nach dieser Anleitung vorgegangen:
http://www.fhemwiki.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben (http://www.fhemwiki.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben)
Die Punkte 5-10 habe ich jedoch weggelassen. Zeitzone, Sprache, Tastatur, WLAN habe ich wieder über die Benutzeroberfläche von Raspbian eingestellt.
Ab Punkt 11 habe ich dann hier:
http://www.fhemwiki.de/wiki/Raspberry_Pi#Debian-Repository (http://www.fhemwiki.de/wiki/Raspberry_Pi#Debian-Repository)
weitergemacht. Konkret, alles was unter Manuell steht.
Anschließend habe ich noch das Zusatzpaket libdatetime installiert.
UND JETZT IST TTYS0 WIEDER NICHT VORHANDEN!!!!!!!!!!!!
Ich werde Wahnsinnig!!!!!!!!!!!!!!!!
1.
Zitattail: Fehler beim Lesen von ,,/dev/ttyS0": Eingabe-/Ausgabefehler
Bist Du Dir mit /dev/ttyS0 sicher?
2.
Laut Doku ist es nicht ttyS0 sondern ttyAMADXX ... das mal probiert?
No. busware-Aleitung:
for a RPi 3:
define SCC CUL /dev/ttyS0@38400 1234
Grüße, Markus
Aber auch busware können Fehler unterlaufen.
Hi,
Also als Feedback zu Deinem Test auf der Test SD:
1.) Gleicher Fahler wie im Log unter FHEM
2.) Daher ist entweder etwas mit der Hardware oder mit der Zuordnung zum Software Device nicht richtig!
Woher kommt den der ttyS0 ist da ein Modul für geladen oder wie macht der RPi3 diese Software Serial Schnittstellenzuordnung?
Ich habe mal einen Beitrag gelesen, indem wurde das Onboard Bluetooth deaktiviert und anschliessend der GPIO Serial wieder auf ttyAMA0 gelegt... Hat hier noch hemand die Hintergründe für den Fehler oder kennt sich mit dem RPi3 besser aus?
So nach einer Recherche zum Thema RPi3 und GPIO Serial habe ich diesen Artikel gefunden: http://www.briandorey.com/post/Raspberry-Pi-3-UART-Overlay-Workaround
Hintergrund: die Baudrate des Software Serial Interface ist nicht stabil. Könnte das der Fehler sein?
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Kurzes Update.
Nachdem ich gestern Abend mal wieder feststellen musste, das ttyS0 nach einem "upgrade" verschwunden ist, habe ich mich heute Morgen erneut daran gesetzt und nochmal alles OHNE Update installiert. wenn ich jetzt das SCC definiere, erhalte ich die Fehlermeldung:
2016.05.29 10:00:11 3: Opening SCC device /dev/ttyS0
2016.05.29 10:00:11 3: Can't open /dev/ttyS0: Keine Berechtigung
Also lasse ich mir die Berechtigungen für ttyS0 anzeigen und sehe, das nur root Berechtigung hat. Ich befolge also die Anweisung von Arnd und verknüpfe ttyS0 mit dialout. Nach einem Neustart von fhem habe ich immer noch keine Berechtigung. Nach einem Neustart des raspberry ändert sich auch nichts.
In meiner Verzweifelung habe ich kurzerhand einmal die Dateirechte füt ttyS0 von 640 auf 666 gesetzt. Danach reagiert fhem aber nicht mehr. Nach einem Neustart des raspberry ist aber alles wieder beim alten.
So langsam vergeht mir die Lust.
Hallo,
vielleicht hilft das:
https://forum.fhem.de/index.php/topic,52105.msg438551.html#msg438551 (https://forum.fhem.de/index.php/topic,52105.msg438551.html#msg438551)
Gruß, Joachim
Hi,
Ja genau das ist der Thread in dem Bluetooth deaktiviert wird um die GPIOs vernünftig zu nutzen!
Meine Lösung w/ den Berechtigungen läuft nur mal kurzzeitig, soll heissen nach dem Reboot war wieder nur root im Besitz des Devices!
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Hallo
Das war ja die Anleitung, nach der ich gestern Nachmittag auf meiner test SD vorgegangen bin. Dabei hatte ich versucht, das SCC mit ttyS0 zu verbinden (was ja nach dem upgrade gefehlt hatte). Darum hatte ich das ganze ja noch mal gemacht, ohne upgrade. Da kam dann aber immer die Fehlermeldung von gestern Abend.
Ich habe die aktuelle Installation jetzt so umgestellt und auch alle updates / upgrades durchgeführt. Dann definiere ich das SCC wieder mit ttyAMA0. Jetzt wird es erkannt, aber nicht initialisiert.
2016.05.29 16:11:21 3: Opening SCC device /dev/ttyAMA0
2016.05.29 16:11:21 3: Setting SCC serial parameters to 38400,8,N,1
2016.05.29 16:11:21 3: SCC device opened
2016.05.29 16:11:30 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Das hatten wir doch auch schon, oder?
Du hast folgendes gelesen?
tps://forum.fhem.de/index.php/topic,52105.msg438551.html#msg438551 (http://tps://forum.fhem.de/index.php/topic,52105.msg438551.html#msg438551)
Danach bin ich ja vorgegangen.
Dort steht aber nichts von ttyS0...
das steht aber in der busware-Anleitung. Ich denke, dass die beiden unterschiedlichen Anleitungen für Verwirrung gesorgt haben und aktueller Stand die Vorgehensweise nach dem Forumsthread ist, also ttyAMA0 zu definieren ist.
@edition: Ich hab mal ins Modul geguckt: Der INIT scheitert ja. Mit verbose 5 sollten noch weitere Infos im Log landen. Vielleicht helfen die ja weiter. Nur so 'ne Idee....
Markus
Nein, leider wird im Log auch nicht mehr angezeigt, wenn ich auf verbose 5 wechsele.
Kann ich das SCC nicht auch irgendwie anders ansprechen? mit einem Befehl aus der Konsole, oder so?
Hi, Doch kannst Du! Ist auch weiter oben in Thread #30 schon beschrieben worden!
Du hast aber auf der Kommandozeile den gleichen Fehler - wie ich Dir in einer PM auch schon geschrieben habe.
Ich weiß inzwischen von dem merkwürdigen Verhalten im RPi3, müsste aber auf der Shell selbst mal nachsehen. Der Linux Grundkurs über das Forum - ohne Detail Infos von Dir - und mit Deiner Hektik (ständiges Neuaufsetzen der Systeme) hilft Dir nicht weiter ;-)
Also kurzum: Mach mal ruhiger und lass uns an den Infos (Logdateien und Kommandozeilen Antworten) teilhaben.
Und wenn Du dann die weiteren Rückfragen abwartest, können wir auch systematisch helfen.
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Sorry für das hektische hin und her zwischen den unterschiedlichen Installationen. Ich wollte damit herausfinden, wo ttyS0 geblieben ist. Darauf hatte ich mich versteift. Da ich jeweils so viele Sachen ausprobiert habe, das ich nicht mehr genau wusste, ob ich damit nicht etwas kaputt gemacht habe, habe ich halt lieber von vorne angefangen.
Aber nochmal zurück zur Antwort 29. Wenn ich das jetzt mache, bekomme ich keine Ausgaben.
Fhem ist gestopt und ich habe zwei Putty Fenster geöffnet. Im ersten gebe ich ein:
sudo tail -f /dev/ttyAMA0
Außer, das der Curser eine Zeile nach unten springt, passiert gar nichts.
Im zweiten Fenster gebe ich ein:
sudo echo "v" >/dev/ttyAMA0
und lande wider am eingabepromt. Es erfolgt keine Ausgabe.
Nach Eingabe des Befehls im 2. Fenster hätte im 1. die Rückmeldung kommen müssen.
Du hattest die Anpassungen im fhem-Startskript gemacht und fhem gestartet und mit shutdown wieder gestoppt ?
Mit ls -la /dev/ttyA* bekommst Du das ttyAMA0 angezeigt ? Mit welchen Berechtigungen ?
Wird schon werden, Markus
Hi Markus,
Gibt es auch LEDs an Deinem CUL? Blinkt da etwas beim zweiten Befehl?
tail -f(ollow) bedeutet: zeige alles an was auf diesem Interface ist oder noch erscheint.
Echo gibt das v(ersion) an das Interface und ein CUL sollte mit seiner Versionsnummer antworten.
Hast Du auch eine ttyS0? Falls ja: Was passiert bei den beiden Befehlen oben bei ttyS0? Falls nein: Wie sieht deine /boot/cmdline.txt aus?
Wie gehst Du auf den RPi per Tastatur/Monitor oder per ssh/putty vom PC übers Netz? Einige berichten, dass bei ssh Verbindungen die Timings auf der Seriellen ttyS0 Schnittstelle besser sein sollen.
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Hi Arnd,
ich hab weder einen RPi3 noch ein SCC. Ich hab das mit meinem USB-CUL am Rpi2 mit wheezy getestet.
ttySC0 kommt ja immer ins Spiel(auch von mir :-[), weil das so in der busware-Anleitung für RPi3 mit SCC steht. Aber jetzt hat Edition ja die Vorgehensweise aus dem Forenthread gewählt.
LED blinkt nicht, aber möglicherweise habe ich das ja abgestellt ?
Bei mir ist die Antwort nicht die Firmware-Version und Frequenz, sondern die typische Fehlermeldung, wenn das CUL-Kommando falsch ist :o
(Für mich überraschenderweise) kommt aber beim fhem-start die richtige Antwort mit Firmware und Frequenz im 1. Fenster. Und das sogar 2 mal. Spekulation: 1*mal beim open und 1mal beim init des CUL ? Wäre doch interessant, was bei Edition im 1. Fenster bei einem fhem-start erscheint(sofern er denn ein ttyAMA0 hat)
Grüße, Markus
Edit: ich greife per putty auf den Rpi zu.
Da ich jetzt nicht weis, ob Deine Serielle Schnitstelle überhaupt gut initialisiert wurde, probiere doch bitte auch auf der Konsole:
minicom -b 38400 -o -D /dev/ttyAMA0
V ENTER
Ausgabe bei mir:
V 1.66 CSM868
Zitat aus einem von mir verlinkten Forumsbeitrag.
Hi,
das ist eine gute Idee!
Zur Erklärung:
Minicom ist ein Terminalprogramm, das evtl mit "sudo apt-get -y minicom" installiert werden muss.
-b ist die Baurate also Geschwindigkeit der Kommunikation (evtl. lohnt auch 9600 oder 115200)
-D ist das Device (ruhig beide testen!)
-o kenne ich nicht auswendig (lokales Echo?), aber "minicom --help" wird es Dir verraten ;-)
Und immer schön schreiben was Du als Antwort erhälst! Auch kryptische Zeichen sind gut - ein Hinweis auf die falsche Gescheindigkeit!
Wird schon!!!
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
ZitatUnd immer schön schreiben was Du als Antwort erhälst! Auch kryptische Zeichen sind gut - ein Hinweis auf die falsche Gescheindigkeit!
Dieses möchte ich nochmals betonen! Es ist gut, wenn Du versuchst zu verstehen, was passiert, ABER bitte nicht "vorfiltern".
Denn wie schon geschrieben:
Ohne Input kein Output ...
Hi
Hat sich ja einiges getan, seit ich gestern hier raus bin. Wolln mal sehn, was ich auf eure Vorschläge für Ausgaben bekomme. Also:
Wenn ich ls -la /dev/ttyA*eingebe, bekomme ich:
crw-rw---- 1 root dialout 204, 64 Mai 30 15:35 /dev/ttyAMA0
Das sollte soweit richtig sein, oder?
Jetzt teste ich minicom. (ist installiert)
Auf die Eingabe minicom -b 38400 -o -D /dev/ttyAMA0 erscheint bei mir:
Willkommen zu minicom 2.7
Optionen: I18n
Übersetzt am Jan 12 2014, 05:42:53.
Port /dev/ttyAMA0, 15:35:22
Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten
Also Ctrl und A gedrückt.
Dann ändert sich der untere Teil des Fensters zu weißem Hintergrund mit schwarzer Schrift. Leider lässt sich das nicht rauskopieren. aber da steht, von links nach rechts:
CTRL-A z for help | 38400 8N1 | NOR | Minicom 2.7 | VT102 | Offline | ttyAMA0[code]
Das Offline macht mich stutzig!
Ich knn dann z drücken und erhalte eine Tabelle mit verschiedenen Befehlen.
[code] Minicom-Kommandoübersicht |
Optio| |
Übers| Kommandos werden mit CTRL-A <Taste> au |
Port | |
| Zentrale Funktionen Andere Funktionen |
Drück| |
| Telefonbuch........D Skript ausführen...G | Bildschirm löschen.C |
| Dateien senden.....S Dateien empfangen..R | Konfiguration......O |
| Kommunikation......P Zeilenvorschub.....A | Minicom unterbr....J |
| Protokoll..........L Auflegen...........H | Ende und Reset.....X |
| Break senden.......F Modem init.........M | Ende ohne Reset....Q |
| Terminalparameter..T Kermit aufrufen....K | Pfeiltastenmodus...I |
| Zeilenumbruch......W lokales Echo ......E | Hilfe..............Z |
| Datei einfügen.....Y Zeitstempel an/aus.N | Scroll Back........B |
| Sende Carriage Ret.U |
| |
| Wählen Sie eine Funktion aus oder Enter zum Verlassen. |
Mit welchem Befehl kann ich nun sehen, ob alles richtig eingestellt ist? V ist nämlich nicht dabei.
Das sind die Befehle bzw. die Hilfe zu minicom.
Einfach wieder raus aus der Hilfe und im "normalen" Terminal (minicom):
V + 'Enter'
Dann sollte wie bei Wernieman angegeben die Version des CUL/SCC kommen...
Nein, keine Reaktion. Auf keine Taste. Nur Ctrl (oder Strg) &A bewirkt, das die Schrift im unteren Teil erscheint. Jede weitere Taste lässt sie wieder verschwinden, außer Q, oder X, oder... Alles was in der Tabelle angegeben ist. Aber kein V!
Ich weiß jetzt nicht genau was du meinst.
Am Besten die Console schließen.
Eine neue aufmachen und dann den minicom wieder starten minicom -b 38400 -o -D /dev/ttyAMA0
Danach dann 'V' und 'Enter'...
BTW:
Du hast gesehen, das folgende der Forumsbeitrag ähnlich zu Deinem Problem ist und mittlerweile aktuallisiert wurde?
https://forum.fhem.de/index.php/topic,47046.0.html (https://forum.fhem.de/index.php/topic,47046.0.html)
Ich glaube mittlerweile eher, Du hast ein HW-Problem ....
Das meine ich ja: wenn ich minicom -b 38400 -o -D /dev/ttyAMA0 eingebe und enter drücke, erscheint das was ich oben beschrieben habe. Willkommen zu Minicom etc. Ich kann dann alle Tasten drücken, ohne das etwas passiert. Erst wenn ich Strg & a drücke, kann ich anschließend die Buchstaben verwenden, die in der Tabelle angegeben sind. Aber kein V!
Wie gesagt, macht mich das Offline stutzig, was unter anderem bei Strg & a erscheint. Das soll doch was sagen, oder?
Ich habe den aktualisierten Forumsbeitrag gelesen und mal meine /boot/config.txt überprüft. Bei mir steht:
# Allow the normal UART pins to work
dtoverlay=pi3-disable-bt-overlay
Im Beitrag steht: dtoverlay=pi3-disable-bt
Sollte es das sein, oder hat er nur nicht zu Ende geschrieben?
Mit Putty komme ich auch nicht ins Verzeichniss /boot/overlays!
Mit Filezilla kann ich aber unter /boot das Verzeichniss /overlays sehen. Wenn ich es öffne, gibt es keine Datei namens pi3-disable-bt-overlay.dtb.
Aber es gibt eine namens pi3-disable-bt.dtbo.
Kann es das sein?
Ich habe es einfach mal geändert und den raspi neu gestartet. Hier das log:
2016.05.30 17:16:57 0: Server shutdown
2016.05.30 17:17:03 1: Including fhem.cfg
2016.05.30 17:17:03 3: telnetPort: port 7072 opened
2016.05.30 17:17:03 3: WEB: port 8083 opened
2016.05.30 17:17:03 3: WEBphone: port 8084 opened
2016.05.30 17:17:03 3: WEBtablet: port 8085 opened
2016.05.30 17:17:04 2: eventTypes: loaded 1 events from ./log/eventTypes.txt
2016.05.30 17:17:04 3: Opening SCC device /dev/ttyAMA0
2016.05.30 17:17:04 3: Setting SCC serial parameters to 38400,8,N,1
2016.05.30 17:17:04 3: SCC device opened
2016.05.30 17:17:04 3: SCC: Possible commands: mBbCFiAZGMYRTVWXef*ltuxz
2016.05.30 17:17:04 2: Setting CUL fhtid from FFFF to 1234
2016.05.30 17:17:04 1: Including ./log/fhem.save
2016.05.30 17:17:04 2: SecurityCheck: WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.05.30 17:17:04 0: Featurelevel: 5.7
2016.05.30 17:17:04 0: Server started with 9 defined entities (fhem.pl:11476/2016-05-18 perl:5.020002 os:linux user:fhem pid:706)
2016.05.30 17:17:13 3: FHT Unknown device 1b4a, please define it
2016.05.30 17:17:13 2: autocreate: define FHT_1b4a FHT 1b4a
2016.05.30 17:17:13 2: autocreate: define FileLog_FHT_1b4a FileLog ./log/FHT_1b4a-%Y.log FHT_1b4a
2016.05.30 17:17:13 2: autocreate: define SVG_FHT_1b4a SVG FileLog_FHT_1b4a:fht:CURRENT
2016.05.30 17:17:42 3: FHT Unknown device 3232, please define it
2016.05.30 17:17:42 2: autocreate: define FHT_3232 FHT 3232
2016.05.30 17:17:42 2: autocreate: define FileLog_FHT_3232 FileLog ./log/FHT_3232-%Y.log FHT_3232
2016.05.30 17:17:42 2: autocreate: define SVG_FHT_3232 SVG FileLog_FHT_3232:fht:CURRENT
Ich glaube das war es, oder?
Hi,
Ja sieht so aus ;-)
Der Befehl in der cmdline.txt (Die Du uns immer noch schuldest ;-) bewirkt, dass das interne Bluetooth Dongle deaktiviert wird.
Hier ist auch eine spannende Quelle dazu:
http://www.forum-raspberrypi.de/Thread-raspbian-raspi-3-wie-uart-umbiegen
Gruß Arnd
FHEM auf Raspberry Pi, CUL, Signalduino, Intertechno, WifiLight2 mit H801 - ESP8266, ...
Nein, nicht cmdline.txt, sondern /boot/config.txt. Hier stand bei mir:
dtoverlay=pi3-disable-bt-overlay
Es gibt bei mir aber keine passende Datei dazu. Stattdessen habe ich pi3-disable-bt.
Darum habe ich die Config angepasst und nun geht es.
Jetzt muss nur noch das 2. SCC drauf (433MHz für Intertechno).
Hallo zusammen
Da nun alles funktioniert, möchte ich mich bei allen, die mir mit ihren Ratschlägen und Tipps zur Seite gestandenhaben, bedanken.
Es tut immer wieder gut, zu wissen, das sich in solchen Foren Leite aufhalten, die Anfängern wie mir helfen, wenn sie mit der neuen Materie nicht mehr weiterkommen.
Ich habe auch das zweite SCC in Betrieb genommen und meine Intertechno Steckdosen in Betrieb genommen. Jetzt geht es an die weitere Programmierung. Ein Homematic Jalousieaktor ist zum testen bestellt.
Ich denke, wenn es damit in die Vollen geht (Stichwort Google Kalender), werde ich wieder Rat hier im Forum suchen.
Bis dahin, mit herzlichstem Dank
edition
Da ich jetzt den Überblick verloren habe .. woran lag es denn eigentlich?
Am Verweis auf die Datei namens pi3-disable-bt-overlay.dtb in der /boot/cinfig.txt, wie es in der Anleitung
https://forum.fhem.de/index.php/topic,47046.0.html
beschrieben war. Du selbst hattest mich darauf aufmerksam gemacht, das der Beitrag aktualisiert wurde.
Diese war bei mir nicht vorhanden. Kann sein, das es auch hier durch update / upgrade dazu kommt.
Die vorhandene Datei hieß bei mir pi3-disable-bt.dtbo. So hatte es auch Roland auch in Antwort 14 geschrieben.
Mit der entsprechenden Änderung in /boot/config.txt ging es dann.
Daher noch mal Danke, für den entscheidenen Tipp!
Gruß
edition