Hallo Zusammen,
ich hoffe jemand kann mir helfen. Ich bin leider nicht sehr versiert und komme nicht weiter.
Nachdem ich auf meinen Raspberry Model B Plus eine ganz neue SD Card mit Buster lite aufgesetzt und FHEM zurückgespielt habe sieht alles erst mal gut aus.
Leider lässt sich der Busware SCC 1101 (Fs 20 Mode) auf dem Gpio nicht mehr öffnen.
Beim Fhem Start habe ich jedes mal die Meldung disconnected.
Ich muss nach jedem Start des Raspberry mit sudo chown fhem /dev/ttyAMA0 die Rechte neu vergeben.
Dann bekomme ich zwar connected, aber im Log steht noch immer Cannot init /dev/ttyAMA0, ignoring it (SCC).
Ich habe einige Einträge aus dem Forum bereits versucht umzusetzen, komme aber nicht weiter.
Kann mir jemand noch eine Idee geben ?
Kann es sein dass es mit Buster lite und dem alten Raspberry B Plus nicht läuft ?
Wenn ich meine alter SD Carte in den Raspi stecke mit Wheezy, dann läuft alles normal.
Vielen dank für jeden Tipp im voraus
Möchte noch zu meinem Post ergänzen:
die Meldung im Log sieht so aus:
2019.12.07 20:02:45 3: Opening SCC device /dev/ttyAMA0
2019.12.07 20:02:46 3: Setting SCC serial parameters to 38400,8,N,1
2019.12.07 20:02:55 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
bei Abfrage der Schnittstelle kommt:
pi@raspberrypi:~ $ ls -l /dev/ser*
lrwxrwxrwx 1 root root 7 Dec 7 19:17 /dev/serial0 -> ttyAMA0
ich benutze nur FS 20 Komponenten
habe alles möglich versucht und komme nicht weiter.
Wäre sehr nett wenn ich eine Antwort bekomme.
Eine Suche im Internet nach "Raspbian buster disable console" fuehrt mich zu der Annahme, dass ttyAMA0 von der Console belegt ist, und das per raspi-config abschaltbar ist.
Getestet habe ich es aber mangels Hardware nicht.
Hi,
ZitatLog: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Unter Buster kann ich einfach den SCC 1101 nicht mehr erreichen.
Sobald ich meine alte Wheezy Karte reinstecke läuft alles normal.
Diese Fehlermeldung lässt mich zum gleichen Schluß kommen wie Rudi.
Ich habe mal diesen Abschnitt verfasst/überarbeitet. https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Ist der Consolen Dienst wirklich deaktiviert?
Ich muss offenbar diesen Abschnitt mal unter Buster testen.
Gruß Otto
Hallo Otto,
danke für deinen Input. Ich dachte schon ich langweile das Forum, weil zunächst keine Antwort kam. >:(
Bei der Kontrolle der seriellen Schnittstelle
sieht die Ausgabe gut aus.
Der Befehl ls -l /dev/ttyAMA0 muss folgende Ausgabe liefert.
crw-rw---- 1 root dialout 204, 64 Jun 7 22:56 /dev/ttyAMA0
Auch konnte ich den SCC auf die neuest Firmware aktualisieren.
Somit gehe ich davon aus, das die Schnittstelle funktioniert.
In FHEM wird der SCC als opened angezeigt.
ein get config SCC scheitert aber weiterhin.
Somit stellt sich mir die Frage, hat ein Anwerder unter Buster ein SCC Modul jemals ins laufen gebracht ?
Noch eine Verständnisfrage:
Die Kontrolle von /dev/serial gibt richtig aus:
lrwxrwxrwx 1 root root 7 Jun 8 18:30 /dev/serial0 -> ttyAMA0
Somit sollte doch bestätigt sein, daß das Problem lediglich beim Zugriff aus FHEM erfolgt, Richtig ?
Sollte ich ein CUL (USB) kaufen um es mit Buster ins laufen zu bekommen ?
Oder einen neuen Raspi 3 ?
Ich weiss mir keinen Rat mehr.
Gruss
KLAUS
Im FHEM log weiterhin die Meldung
2019.12.07 20:02:45 3: Opening SCC device /dev/ttyAMA0
2019.12.07 20:02:46 3: Setting SCC serial parameters to 38400,8,N,1
2019.12.07 20:02:55 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Die wahrscheinlichste Ursache nach allen bisherigen Informationen ist, dass auch eine weiteres Applikation, vermutlich die Console, die serielle Schnittstelle geoeffnet hat. Anders formuliert: die Antwort des SCC wird von der Console-Applikation weggelesen, FHEM bekommt nichts, und meldet nach Timeout den Fehler.
Was sagt denn
systemctl status serial-getty@ttyAMA0.service
Gruß Otto
Hallo Otto,
es sagt:
● serial-getty@ttyAMA0.service
Loaded: masked (Reason: Unit serial-getty@ttyAMA0.service is masked.)
Active: inactive (dead)
noch eine Kopie aus dem Log:
Haben diese Fehlermeldungen PERL WARNING evt. damit zu tun ?
2019.12.09 14:25:58 3: Opening SCC device /dev/ttyAMA0
2019.12.09 14:25:58 3: Setting SCC serial parameters to 38400,8,N,1
2019.12.09 14:26:19 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
2019.12.09 14:26:19 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^(\+)?(\*({ <-- HERE \d+})?)?(.*)$/ at ./FHEM/90_at.pm line 64, <$fh> line 100.
2019.12.09 14:26:19 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^(\+)?(\*({ <-- HERE \d+})?)?(.*)$/ at ./FHEM/90_at.pm line 212, <$fh> line 100.
2019.12.09 14:26:22 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE .*})$/ at ./FHEM/98_SVG.pm line 1488, <$fh> line 442.
2019.12.09 14:26:22 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE .*})$/ at ./FHEM/98_SVG.pm line 1722, <$fh> line 442.
Nein. Sicher.
Welche Perl Version verwendest du?
Mit perl 5.30 kriege ich diese Meldung nicht.
Hallo Rudolf
This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 61 registered patches, see perl -V for more detail)
Hallo Otto,
ich habe deine Frage wie folg beantwortet:
das System sagt:
● serial-getty@ttyAMA0.service
Loaded: masked (Reason: Unit serial-getty@ttyAMA0.service is masked.)
Active: inactive (dead)
heißt das, hier liegt mein Problem ?
inactive (dead) ??
Ich verstehe das nicht, denn ich konnte ja den SCC die Firmware aktualisieren.
Also ist er doch eigentlich aktiv ?
Oder verstehe ich das falsch ?
Gruss
KLAUS
Wie schaut das FHEM-Log mit "attr global verbose 5" aus?
Zur Ergänzung:
nachdem ich im Forum folgendes gefunden habe:
sudo systemctl unmask serial-getty@ttyAMA0.service
sudo systemctl enable serial-getty@ttyAMA0.service
sudo systemctl start serial-getty@ttyAMA0.service
kommt nun:
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Dec 9 19:31:47 2019 from 192.168.0.11
pi@raspberrypi:~ $ systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; enabled; vendor pr
Active: active (running) since Mon 2019-12-09 19:32:23 CET; 38s ago
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Main PID: 416 (agetty)
Memory: 140.0K
CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA0.servi
└─416 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyAMA0
Dec 09 19:32:23 raspberrypi systemd[1]: Started Serial Getty on ttyAMA0.
lines 1-12/12 (END)
Trotzdem immer noch keine Funktion >:(
Hallo Rudolf
es sieht so aus.
Ich hoffe ich habe es richtig erzeugt
2019.12.09 19:58:40 4: WEB_192.168.0.11_51231 GET /fhem?XHR=1&inform=type=status;filter=;since=1575917919;fmt=JSON&fw_id=657×tamp=1575917920792; BUFLEN:0
2019.12.09 19:58:43 4: Connection closed for WEB_192.168.0.11_51231: EOF
2019.12.09 19:58:43 4: Connection accepted from WEB_192.168.0.11_51233
2019.12.09 19:58:43 4: WEB_192.168.0.11_51233 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0
2019.12.09 19:58:44 4: WEB_192.168.0.11_51233 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1575917922;fmt=JSON&fw_id=659×tamp=1575917924011; BUFLEN:0
2019.12.09 19:59:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 19:59:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:00:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:01:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:01:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:02:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:02:35 5: exec at command Initializedreset
2019.12.09 20:02:35 5: Cmd: >IF ([WZ_Fussbautom:state] eq "Initialized") (set WZ_Fussbautom on)<
2019.12.09 20:02:35 5: Cmd: >{if(ReadingValIf('WZ_Fussbautom','state','') eq "Initialized"){fhem('set WZ_Fussbautom on')}}<
2019.12.09 20:02:35 5: redefine at command Initializedreset as +*00:10:00 IF ([WZ_Fussbautom:state] eq "Initialized") (set WZ_Fussbautom on)
2019.12.09 20:02:35 5: Starting notify loop for Initializedreset, 1 event(s), first is Next: 20:12:35
2019.12.09 20:02:35 5: createNotifyHash
2019.12.09 20:02:36 5: End notify loop for Initializedreset
2019.12.09 20:03:00 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:03:01 5: IP: 192.168.0.12 -> 192.168.0.12
2019.12.09 20:03:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:03:01 5: IP: 192.168.0.27 -> 192.168.0.27
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51248
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem; BUFLEN:0
2019.12.09 20:03:13 4: WEB: /fhem / RL:1449 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51249
2019.12.09 20:03:13 4: Connection accepted from WEB_192.168.0.11_51250
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51249 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2019.12.09 20:03:13 4: WEB_192.168.0.11_51250 => 304 Not Modified
2019.12.09 20:03:13 4: WEB_192.168.0.11_51248 GET /fhem?XHR=1&inform=type=status;filter=;since=1575918192;fmt=JSON&fw_id=660×tamp=1575918193510; BUFLEN:0
2019.12.09 20:03:15 4: Connection closed for WEB_192.168.0.11_51248: EOF
2019.12.09 20:03:15 4: WEB_192.168.0.11_51250 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2019-12.log; BUFLEN:0
Mit "verbose 5 log" meinte ich das Initialisieren von SCC, also beim FHEM Startup, oder wenn man ein "set SCC reopen" durchfuehrt, d.h. da, wo auch die Meldung "Cannot init" erscheint.
Und bitte das "verbose 5 log" unbedingt _ohne_ diesen getty Dienst testen, sonst bestaetigt das FHEM-Log nur meine Beschreibung von heute um 11:11
Hallo Klaus,
was Du in #13 gezeigt hast ist absolut in Ordnung.
Mit Deiner Aktion in #15 (was das ganze Gegenteil von dem ist was im Wiki steht) hast Du den Consolen Dienst wieder aktivert. Damit kann AM UART kein Modul richtig funktionieren. Zumindest ist das beim HMUART Modul so.
Also mach das bitte rückgängig, der Consolendienst (serial-getty) würde die Kommunikation mit der Schnittstelle verhindern/stören.
Aber ich habe keinen SCC und rede nur Theorie die ich vom HMUART Modul habe. Offenbar hat aber auch kein Anderer den SCC oder ist in der Lage zu helfen
Gruß Otto
Hallo Rudi,
hier das Ergebnis:
2019.12.09 21:00:00 5: SCC sending F1b1b2038ce
2019.12.09 21:00:00 5: SW: F1b1b2038ce
2019.12.09 21:02:12 3: Setting SCC serial parameters to 38400,8,N,1
2019.12.09 21:02:12 5: SW: V
2019.12.09 21:02:15 5: SW: V
2019.12.09 21:02:18 5: SW: V
2019.12.09 21:02:21 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Hallo Otto,
ja, du hast Recht.
ich habe es soeben rückgängig gemacht.
Danke Euch Beiden .....
Das Log sagt: FHEM kann schreiben, kriegt aber keine Daten.
Entweder gibt es noch weitere Prozesse die auf diese Schnittstelle zugreifen (z.Bsp. getty war noch configuriert), oder es gibt ein Problem weiter "unten" (Treiber/Verdrahtung/Firmware/etc). Ich meine mit fuser (https://linux.die.net/man/1/fuser) kann man rauskriegen, welche Prozesse eine Datei geoeffnet haben.
culfw kann man auch ohne FHEM testen: man verbindet sich direkt (z.Bsp. mit "screen /dev/ttyAMA0"), und man tippt (blind) die Befehle ein: V<RETURN> sollte Versionsinfo liefern, t<RETURN> uptime, usw, siehe http://culfw.de/commandref.html
Hallo Klaus,
hier gab es auch mal einen Anleitung. Vor allem die GPIO Befehle hast Du ausgeführt? Das funktioniert problemlos?
https://forum.fhem.de/index.php/topic,66670.0.html#ratethis
Gruß Otto
ohh, ich gebe auf.
Bestelle mir jetzt einen CUL USB Stick von Busware.
Mal sehen ob es damit dann läuft.
Wenn es dann immer noch nicht funktioniert, liegt es wohl an Buster.
Danke jedenfalls für Eure Mühe
Für welche Anwendung? Für Homematic nimm lieber was anderes ...
Ich habe derzeit immer noch mu FS 20 im Einsatz.
Zu viele Aktoren die ich nicht alle austauschen möchte
Ja stimmt - ich erinnere mich.
Schade tut mir leid, dass niemand einen besseren Tipp hat.
Hallo Otto,
Hallo Rudi,
danke trodzdem Euch beiden.
Ich werde berichten ob es dann final mit dem USB CUL geklappt hat.
Interessant wäre zu erfahren, ob hier im Forum jemand einen Busware SCC auf Raspi mit Buster ins laufen gebracht hat.
Gruss aus dem Allgäu
Klinke mich mal ein.
Bei mir ist über Weihnachten ein Umzug von Raspi2 Wheezy auf Raspi4 Buster geplant.
Ich nutze ebenfalls noch einen SCC, den ich erneut einsetzen möchte.
Ich werde dann im Forum berichten.
Gruß Helmut
ich bin immer noch hartnäckig auf der Fehlersuche.
SCC lässt sich nach wie vor unter Buster nicht öffnen.
Kann mir jemand sagen wie ich feststellen kann, ob FHEM auf meinem Raspberry unter dem Benuterz Pi oder Benutzer FHEM angelegt wurde.
sorry für die dumme Frage... ich weiss Newbies nerven ;)
Oder spielt das am Ende keine Rolle ?
Die Rechte unter @pi sollten umfänglich passen.
Unter @fehm kann ich es nicht prüfen, weil ein Passwort verlangt wird.
(Ich habe keines vergeben und verstehe das auch nicht)
normalerweise läuft FHEM unter user fhem.
ps -aux|grep fhem
Das ist aber bezüglich der Rechte auf dem SCC nicht das Problem.
fhem sollte Mitglied der Gruppe dialout sein
groups fhem
Hallo Otto,
ja das habe ich extra geprüft. FHEM ist Mitglied der Gruppe dialout.
Versstehe ich richtig daß somit die Rechte jedenfalls nicht das PRoblem sein können ?
Hier die Meldung
pi@raspberrypi:~ $ groups fhem
fhem : dialout tty gpio
Ich denke eher die notwendigen GPIO Ports sind nicht aktiviert und/oder der SCC kann nicht senden.
Du hast doch die Installationshinweise beachtet?
http://busware.de/tiki-index.php?page=SCC_Installation (http://busware.de/tiki-index.php?page=SCC_Installation)
Wobei, ich sehe gerade die sind für PI3 und Jessie, eventuell ist das bei Buster ja wieder anders. >:(
So, nun habe ich es nach langem suchen geschafft, einen SCC unter Buster ins laufen zu bekommen.
Ich werde diese Tage noch ausführlicher hier berichten. Womöglich kann es anderen beim Update helfen.
Folgende Frage ins Forum.
Ich kann folgenden (untenstehend) Hinweis nicht umsetzen, (d.h ich muss die gpio Freigabe nach jedem Start des Raspberry manuell eingeben)
da es die Datei /etc/init.d/fhem nicht mehr in Buster gibt.
I
n einem anderen Forumhinweis steht, dies bitte in in /etc/init.d/fhem in Zeile 19 nach FEHM Start eintragen.
Kann mir jemand einen Tipp geben ?
Wo wird FHEM unter Buster gestartet ?
Wo gehört dieser Eintrag unter Buster hin ?
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
In Linux wurde vor langer Zeit init durch systemd abgelöst.
Schon lange wird fhem über die /etc/systemd/system/fhem.service gestartet.
Ich würde das niemals direkt dort eintragen.
Du kannst die drei Zeilen in eine Scriptdatei packen und diese mit ExecStartPre starten.
https://wiki.ubuntuusers.de/systemd/Service_Units/
Aber es gäbe auch andere Wege - ich weiß auch nicht welche der Bessere wäre.
Gruß Otto
Hallo Otto
ich habe es mit einem Cronjob versucht, aber leider habe ich da was falsch gemacht.
Funktioniert nicht.
Du sagtest du würdest das nie in fhem.start eintragen
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
Da ich Angst habe den Raspi mit einem falschen Start Script nicht mehr bootfähig zu haben
meine Bitte und Frage nach deiner Hilfe.
Wie mache ich das damit obige Zeilen bei jedem Reboot vor dem Start von FHEM abgearbeitet werden ?
Gruss
KLAUS
Hallo Klaus,
hab ich doch geschrieben!? Missverständnis?
Du machst ein Script: willi.sh
dort kopierst Du die drei Zeilen rein.
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
Dann testest Du das Script:
sudo bash willi.sh
Wenn das tut was es soll öffnest Du die fhem.service und legst vorher eine Sicherheitskopie an.
sudo cp /etc/systemd/system/fhem.service /etc/systemd/system/fhem.service.org
sudo nano /etc/systemd/system/fhem.service
Wie im Wiki beschrieben schreibst Du dort eine Zeile rein
ExecStartPre bash /DenEchtenPfadzuWilli/willi.sh
Dann machst Du ctrl +o und speicherst das Script, dann ctrl + x zum verlassen von nano.
Dann startest Du den raspberry neu um zu sehen ob alles funktioniert.
Wenn nicht musst Du die fhem.service zurück kopieren.
Gruß Otto
Hallo Otto,
erstmal vielen Dank für deine Hilfe.
die Datei sieht so aus.
# $Id: fhem.service 16001 2018-01-26 11:54:41Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
ExecStartPre bash /home/klausstart.sh
[Install]
--------
Wenn ich meine eigene ExecStartPre bash /home/klausstart.sh einbaue,
lässt sich fhem nicht mehr öffnen.
Ich habe verschiedene Positionen im Script getestet.
Wen ich manuell mit sudo bash auslöse funktioniert es.
Bitte nochmal Hilfe
ich denke Du schreibst die Zeile einfach falsch :'(
Zitat Wiki:
ZitatDie Schlüssel ExecStarPre und ExecStartPost dürfen auch mehrmals mit verschiedenen Befehlen vorkommen. Wichtig ist, dass bei den Werten für die Exec* Schlüssel immer der vollständige Pfad zum Programm/Skript mit angegeben wird, also z.B. ExecStart=/user/local/bin/mein_programm
ExecStartPre=/bin/bash /home/klausstart.shUnd Codetags musst Du noch üben -> https://forum.fhem.de/index.php/topic,71806.0.html
Final würde ich die Script Datei nach /opt/fhem legen ;)
Otto herzlichen Dank..
Das wars....
Jetzt kann ich glücklich ins Bett gehen...... ;D
Du hast mir echt geholfen....
Und abschließend gefragt: Das war jetzt das eigentliche Problem mit SCC und Buster? Oder war da noch was anderes?
Ins Wiki sollte die Lösung schon noch. :)
Gruß Otto
Anbei meine Lösung, um ein Busware SCC unter Buster ins laufen zu bringen
Als erstes: neueste Firmware auf den SCC flashen
Neueste Version FHEM laden
Danach In der:
boot/cmdline.txt
Code: alt:
#console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4
neu:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
in der:
/boot/config.txt
dtoverlay=pi3-miniuart-bt
final dann in der console eingeben:
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
(dies habe ich mit einem Script laut Otto dann automatisiert)
Dann bei Neustart wurde der SCC initialisiert und war erreichbar.
Bei mir hat es so funktioniert. Unter Wheezy war die GIPO ohne dieses Script
erreichbar.
Unter Buster nur unter Eingabe des benannten Script.
Ich hoffe dieser Eintrag hilft anderen Buster "Updater"
Gruss aus dem Allgäu
Hast Du jetzt einen Model B Plus oder einen Pi3 ?
Hallo Otto,
ich habe einen Pi 3.
ok, weil dein ursprüngliche Frage bezog sich ja auf ein B+ :D
Otto das stimmt, ich habe dann extra vor 2 Tage einen neuen Pi3 gekauft um mich auch hier zu Verbessern ;D
Zitat von: Sonic am 17 Dezember 2019, 15:10:06
Anbei meine Lösung, um ein Busware SCC unter Buster ins laufen zu bringen
Als erstes: neueste Firmware auf den SCC flashen
Neueste Version FHEM laden
Danach In der:
boot/cmdline.txt
Code: alt:
#console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4
neu:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
in der:
/boot/config.txt
dtoverlay=pi3-miniuart-bt
final dann in der console eingeben:
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
(dies habe ich mit einem Script laut Otto dann automatisiert)
Dann bei Neustart wurde der SCC initialisiert und war erreichbar.
Bei mir hat es so funktioniert. Unter Wheezy war die GIPO ohne dieses Script
erreichbar.
Unter Buster nur unter Eingabe des benannten Script.
Ich hoffe dieser Eintrag hilft anderen Buster "Updater"
Gruss aus dem Allgäu
Moin,
da ist ja auch noch Helmut, für den hätte ich die Testaufgabe :) mir behagt die Lösung von Klaus bezüglich der cmdline.txt noch nicht ganz. ;)
Ich stehe nach wie vor zu diesem Teil1 der Vorbereitung -> https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Mag sein das zwei Einträge in der config.txt redundant sind, weil sie sowieso vom System so gemacht werden.
Aber der von Klaus gemachte Edit in der cmdline ist mW unnötig.
Deswegen folgender Vorschlag für Helmut zum Test:
Diese Codeblöcke kann man normalerweise, so wie sie sind, komplett ins Terminalfenster "werfen". Aber bitte kontrollieren, je nach Browser und System kann das auch schief gehen!
1. Schritt
sudo su
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
echo "enable_uart=1" >> /boot/config.txt
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
echo "core_freq=250" >> /boot/config.txt
#Neustart
reboot2. Schritt Script erzeugen
cat <<EOF > /opt/fhem/EnableSCC.sh
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
EOF3. Schritt fhem.service ergänzen (nano /etc/systemd/system/fhem.service)
Vor dieser Zeile
ExecStart=/usr/bin/perl fhem.pl fhem.cfgdiese einfügen
ExecStartPre=/bin/bash /opt/fhem/EnableSCC.shGruß Otto
@Otto , ist vllt. hier etwas untergegangen , aber es hat echt lange gedauert bis mal die /boot/cmdline.txt zur Sprache kam.
Im Wiki lese ich davon gar nichts , obwohl IMHO busware auf seiner Seite mal schrieb das dort unbedingt der console=tty1 Part zu entfernen ist.
Aber genau den Part console=tty1 hat er ja jetzt drin gelassen :o er hat console=serial0 entfernt.
Kann man machen, aber die deaktivierung serial-getty@ttyAMA0.service bewirkt mMn genau das Gleiche. Zumindest hab ich das seinerzeit mit dem Hmuart getestet. Und ich habe mich viel damit beschäftigt. Aber ich habe keinen SCC :-[
Mein Problem mit einer Anleitung/Patch für cmdline.txt ist: Die Datei ist quasi bei jeder Systemversion ein bisschen anders. Viele machen einfach copy und paste, ersetzen den kompletten Inhalt, verwenden die falschen Editoren und und und.
Die symbolische Verlinkung der seriellen Schnittstelle hängt auch noch von der pi Version und dem Overlay (config.txt) ab, da gibt es soviele Konstellationen. Da am Ende aber immer alles auf dem ttyAMA0 landet, war das für mich die eindeutigste Lösung. Aber ich kann auch falsch liegen!
Vom SCC find ich im FHEM Wiki bisher gar nichts?
@Otto: Bin gerade dran, Raspberry Pi 4.
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
Muss es beim PI4 nicht
echo "dtoverlay=pi4-miniuart-bt" >> /boot/config.txt
lauten?
Nein, den gibt es nicht.
Ich finde auf https://github.com/raspberrypi/firmware/tree/master/boot/overlays
dies hier:
ZitatName: pi3-miniuart-bt
Info: This overlay has been renamed miniuart-bt, keeping pi3-miniuart-bt as
an alias for backwards compatibility.
Load: <Deprecated>
ZitatName: miniuart-bt
Info: Switch the onboard Bluetooth function on Pi 3B, 3B+, 3A+, 4B and Zero W
to use the mini-UART (ttyS0) and restore UART0/ttyAMA0 over GPIOs 14 &
15. Note that this may reduce the maximum usable baudrate.
N.B. It is also necessary to edit /lib/systemd/system/hciuart.service
and replace ttyAMA0 with ttyS0, unless using Raspbian or another
distribution with udev rules that create /dev/serial0 and /dev/serial1,
in which case use /dev/serial1 instead because it will always be
correct. Furthermore, you must also set core_freq and core_freq_min to
the same value in config.txt or the miniuart will not work.
Load: dtoverlay=miniuart-bt
Params: <None>
Also wäre es so richtiger, der alte Eintrag funktioniert aber!
echo "dtoverlay=miniuart-bt" >> /boot/config.txtMan müsste/könnte beim Pi4 nochmal über den Eintrag core_freq=250 nachdenken, aber auch der ist erstmal nicht falsch, da "Minimum value of core_freq used for dynamic frequency clocking. The default value is 250".
https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
OK.
Alles so eingerichtet.
Der SCC steckt noch am alten FHEM Server
Mit dem Skript startet FHEM nicht.
ExecStartPre=/bin/bash /opt/fhem/EnableSCC.sh
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
(auskommentiert läuft FHEM)
Komisch
hcitool lescan läuft auch nicht mehr. Ist gefixt. Ich habe schon den lepresenced Daemon installiert.
Das könnte die Ursache sein:
Dec 19 11:53:39 fhem systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Dec 19 11:53:39 fhem systemd[1]: Started Update UTMP about System Runlevel Changes.
Dec 19 11:53:39 fhem bash[548]: /opt/fhem/EnableSCC.sh: Zeile 1: /sys/class/gpio/export: Keine Berechtigung
Dec 19 11:53:39 fhem bash[548]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 19 11:53:39 fhem bash[548]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 19 11:53:39 fhem systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 19 11:53:39 fhem systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 19 11:53:39 fhem systemd[1]: Failed to start FHEM Home Automation.
Abhilfe: Da bin ich raus!
hmm da ist jetzt die Frage ist es ein RPI4 Problem oder hat Sonic noch was anderes gemacht.
Kannst Du folgendes manuell absetzen? Kommt da ein Fehler?
sudo su
echo 17 > /sys/class/gpio/export
Keine Meldung und keine FM, im Syslog auch nichts.
By the way - Wieder die permanenten bluetooth Meldungen im Syslog alle 2 Sekunden. Ist gefixt unter Buster!
Dec 19 15:22:59 fhem kernel: [ 1342.960660] Bluetooth: hci0: advertising data len corrected
nano /etc/rsyslog.d/01-blocklist.conf
:msg,contains,"Bluetooth: hci0: advertising data len corrected" ~
und ein ls -lha /sys/class/gpio
root@fhem:/home/pi# ls -lha /sys/class/gpio
insgesamt 0
drwxrwx--- 2 root gpio 0 Dez 19 15:23 .
drwxr-xr-x 62 root root 0 Feb 14 2019 ..
-rwxrwx--- 1 root gpio 4,0K Dez 19 15:23 export
lrwxrwxrwx 1 root gpio 0 Dez 19 15:23 gpio17 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Dez 19 15:00 gpiochip0 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 Dez 19 15:00 gpiochip100 -> ../../devices/gpiochip2/gpio/gpiochip100
lrwxrwxrwx 1 root gpio 0 Dez 19 15:00 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip504
-rwxrwx--- 1 root gpio 4,0K Dez 19 15:00 unexport
root@fhem:/home/pi#
und der Rest?
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
Mir fällt was auf:
mach mal usermod -aG gpio fhem
Wird der Inhalt von fhem.service dann schon als fhem ausgeführt?
root@fhem:/home/pi# echo out > /sys/class/gpio/gpio17/direction
bash: /sys/class/gpio/gpio17/direction: Datei oder Verzeichnis nicht gefunden
und
root@fhem:/home/pi# echo 1 > /sys/class/gpio/gpio17/value
bash: /sys/class/gpio/gpio17/value: Datei oder Verzeichnis nicht gefunden
usermod -aG gpio fhem
Deine Frage verstehe leider ich nicht. Nach Eingabe dieses Befehls passiert nichts auf der Konsole.
Otto, dieses Problem macht mich stutzig, siehe Post oben:
Dec 19 11:53:39 fhem bash[548]: /opt/fhem/EnableSCC.sh: Zeile 1: /sys/class/gpio/export: Keine Berechtigung
Diese FM kommt nur zusammen mit dem Skript zum FHEM Start. Wenn ich das Skrip manuell starte gibt es keine FM.
Otto, ich bin die nächsten Stunden raus. Melde mich heute Abend wieder.
Bis dahin meinen Dank und Respekt für deinen Support!
Helmut (übrgens Helmut Otto genauer gesagt )
Ja kein Problem.
Die Gruppenberechtigung hatte Klaus noch ins Spiel gebracht: usermod ...
Die Fehlermeldung mit der fehlenden Berechtigung ist mir auch unklar.
Egal kriegen wir schon irgendwie gebacken :)
Edit: Hast Du zwischen #56 und #58 neu gestartet?
Kannst Du nochmal in Folge:
sudo su
echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
Ich denke es liegt an den Rechten:
ZitatUser legt fest, unter welchem Benutzer der Service laufen soll (Standard: root)
Mit dem User=fhem Eintrag in der fhem.service wird ja gleich der User fhem zum start genommen. Damit wird das Script EnableSCC auch unter dem User ausgeführt. Damit braucht dieser Benutzer Rechte um die gpio zu bearbeiten. Die bekommt er entweder als root oder als Gruppe gpio.
Zitatlrwxrwxrwx 1 root gpio 0 Dez 19 15:23 gpio17 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio17
Mit dem usermod Befehl haben wir die Gruppe gesetzt, Kontrolle:
groups fhemDu musst aber sicher nochmal starten, damit die Gruppenmitgliedschaft zieht. Danach sollte das Script und der Start laufen.
Gruß Otto
Hallo Otto,
I'll be back hi!
echo 17 > /sys/class/gpio/export
--> Keine FM oder sonst irgendwas
echo out > /sys/class/gpio/gpio17/direction
--> dito
echo 1 > /sys/class/gpio/gpio17/value
--> dito
groups fhem
fhem : dialout audio gpio
Den usermod Befehl - wo habe ich den abgesetzt?
FHEM läuft. Bluetooth ebenso, WLAN ist aus, so war der Plan.
Und der SCC läuft- FW Stand V 1.63 CSM868, Raspberry PI4 und Buster
Ehrlich: Ich habe den Faden verloren. Bin eher Anwendungsentwickler (gewesen)
Eine Anleitung könnte ich jetzt alleine nicht schreiben. ;D
Wenn du mir hilfst, können wir ein SCC Wiki einstellen.
Es gibt im Syslog immer noch FM (der Bluetooth Müll ist weg):
Dec 19 20:44:04 fhem systemd[1]: Reached target Login Prompts.
Dec 19 20:44:04 fhem bash[503]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 19 20:44:04 fhem bash[503]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 19 20:44:04 fhem systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 19 20:44:04 fhem systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 19 20:44:04 fhem systemd[1]: Failed to start FHEM Home Automation.
Dec 19 20:44:05 fhem systemd[1]: Started OpenBSD Secure Shell server.
Dec 19 20:44:05 fhem systemd[1]: Reached target Multi-User System.
Dec 19 20:44:05 fhem systemd[1]: Reached target Graphical Interface.
Dec 19 20:44:05 fhem systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 19 20:44:05 fhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dec 19 20:44:05 fhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Dec 19 20:44:05 fhem systemd[1]: Stopped FHEM Home Automation.
Dec 19 20:44:05 fhem systemd[1]: Starting FHEM Home Automation...
Dec 19 20:44:05 fhem systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Dec 19 20:44:05 fhem systemd[1]: Started Update UTMP about System Runlevel Changes.
Dec 19 20:44:05 fhem systemd[1]: Started FHEM Home Automation.
Hi,
da das mit dem gpio17 ja prinzipiell unabhängig vom SCC geht (ich kann bloß die Auswirkung nicht lesen? Edit: Doch kann ich, ich habe einfach eine LED an GPIO17 gehangen ;)) habe ich jetzt nochmal folgendes durchgespielt:
#Alles als root machen
sudo su
#user fhem muss Mitglied in gpio sein!
usermod -aG gpio fhem
#Script erzeugen
cat <<EOF > /opt/fhem/EnableSCC.sh
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
EOF
#/etc/systemd/system/fhem.service Datei ergänzen (muss schon existieren)
#sed fügt vor der Zeile ExecStart= eine Zeile ein.
#Mann kann es auch per Hand (nano) machen: ExecStartPre=/bin/bash /opt/fhem/EnableSCC.sh
sed -i '/^ExecStart=/ i \ExecStartPre=\/bin\/bash \/opt\/fhem\/EnableSCC.sh' /etc/systemd/system/fhem.service
#Test ob sed alles richtig gemacht hat
cat /etc/systemd/system/fhem.service
# Neustart um die neue Gruppe von user fhem wirksam zu machen
reboot
Der einleitende grundlegende Part der Vorbereitung der UART Schnitttstelle bleibt natürlich!
sudo su
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
echo "enable_uart=1" >> /boot/config.txt
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
echo "core_freq=250" >> /boot/config.txt
#Neustart
reboot
das funktioniert ohne Fehler. Kannst Du das nachvollziehen?
Dec 20 10:30:11 raspib nmbd[599]: Starting NetBIOS name server: nmbd.
Dec 20 10:30:11 raspib systemd[1]: Started LSB: start Samba NetBIOS nameserver (nmbd).
Dec 20 10:30:11 raspib systemd[1]: Starting LSB: start Samba SMB/CIFS daemon (smbd)...
Dec 20 10:30:20 raspib smbd[777]: Starting SMB/CIFS daemon: smbd.
Dec 20 10:30:20 raspib systemd[1]: Started LSB: start Samba SMB/CIFS daemon (smbd).
Dec 20 10:30:20 raspib systemd[1]: Starting Multi-User System.
Dec 20 10:30:20 raspib systemd[1]: Reached target Multi-User System.
Dec 20 10:30:20 raspib systemd[1]: Starting Graphical Interface.
Dec 20 10:30:20 raspib systemd[1]: Reached target Graphical Interface.
Dec 20 10:30:21 raspib systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 20 10:30:21 raspib systemd[1]: Started Update UTMP about System Runlevel Changes.
Dec 20 10:30:21 raspib systemd[1]: Startup finished in 2.675s (kernel) + 44.919s (userspace) = 47.595s.
Edit: Wenn fhem nicht Mitglied der Gruppe gpio ist funktioniert es nicht und es kommt zu den schon von Dir genannten Fehlern.
Gruß Otto
Ich habe noch eine Idee:
Wenn man nicht in der fhem.service herumfummeln will, kann man das Script auch über FHEM beim Start von FHEM aufrufen. Ich weiß nicht ob der SCC damit klar kommt, aber ich denke schon.
define FHEMStart notify global:INITIALIZED "/bin/bash /opt/fhem/EnableSCC.sh"
Hallo Otto,
habe alles nochmal nachgestellt.
Geht leider nicht richtig!
Im Einzelnen:
Syslog:
/opt/fehm/EnableSCC.sh: Zeile 2: ......: Keine Berechtigung
/opt/fehm/EnableSCC.sh: Zeile 3 .......: Keine Berechtigung
groups fhem
fhem : dialout audio gpio
fhem.service meldet dann "scheduling restart", "Stopped FHEM Home Automation", "Starting FHEM Home Automation"
Fhem läuft und der SCC ebenso.
Es kommen dauernd Meldungen ins Log:
2019-12-20 18:06:01 CUL SCC UNKNOWNCODE A0CA6865A388C62000000B0DC2C::-60:SCC
Der SCC läuft mit der gleichen hmid wie mein altes System.
get SCC ccconf
SCC ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Im Fhem Log gibt es folgende Meldung. Ich hatte mal den RFMode geändert.
2019.12.20 18:40:19 1: /dev/ttyAMA0 reappeared (SCC)
Damit hängt der SCC an der ttyAMA0 Schnittstelle
Was ich nicht geändert habe, ist in der Datei cmdline.txt die Zeile mit:
console=serial0, 115200 console tty1
Klaus hatte die Zeile geändert in:
dwc_otg.lpm_enable=0 console=tty1 usw.
Das könnte ich noch mal ändern. --> Hat nichts gebracht.
Gruß Helmut
Zitat von: Otto123 am 20 Dezember 2019, 12:39:53
Ich habe noch eine Idee:
Wenn man nicht in der fhem.service herumfummeln will, kann man das Script auch über FHEM beim Start von FHEM aufrufen. Ich weiß nicht ob der SCC damit klar kommt, aber ich denke schon.
define FHEMStart notify global:INITIALIZED "/bin/bash /opt/fhem/EnableSCC.sh"
Diese Version hat beim Kaltstart (sudo reboot) nicht funktioniert, aber beim "shutdown restart" aus der Fhem Kommandozeile, als Fhem wieder lief.
Die Fehlermeldungen aus dem Fhem Start Skript (fhem.service) sind natürlich weg.
Die permanenten SCC Meldungen im Log sind noch vorhanden.
Ich habe die Definition eines HM Heizungsreglers mal eben von Hand auf den neuen PI4 kopiert - der SCC funktionert gut!
Hier fehlen mit die Linux Kenntnisse:
Das Skript funktioniert tadellos, wie es scheint.
Gibt es nicht eine andere Möglichkeit, das Skript vor dem Start des Skripts fhem.service zu starten (über systemd) ?Gruß Helmut
Hallo Otto,
habe etwas gelesen und dein Script in die Datei /etc/rc.local eingebaut.
# EnableSCC
/opt/fhem/EnableSCC.sh
exit 0
EnableSCC.sh vorher ausführbar gemacht:
sudo chmod 777 EnableSCC.sh
So funktioniert es.
Ich denke, damit können man ein Wiki erstellen?
Gruß Helmut
Hallo Helmut,
viele Wege führen nach Rom. Der erste Satz hier gibt mir zu denken :)
https://wiki.ubuntuusers.de/rc.local/
Zitatrc.local ist seit dem Jahre 1983 obsolet.
ZitatGibt es nicht eine andere Möglichkeit, das Skript vor dem Start des Skripts fhem.service zu starten (über systemd) ?
Das die Idee mit dem notify erst beim restart klappt kann sein, dann war das ne blöde Idee. Haken dran.
Dann bleibt nur die Variante in systemd: ExecStartPre= ....
Warum die bei Dir Fehler wirft ist mir völlig unklar. Hast Du nochmal bei null begonnen?
In der cmdline.txt gibt es nichts zu ändern. Das macht die Befehlsfolge:
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
Ich verstehe es nicht.
Gute Nacht Otto
Hallo Otto,
gute Nacht auch von mir!
Und vielen Dank für das Durchhalten und den Support!
Ich werde mal sehen, wie ich eine Doku anlege.
So ein SCC für HM ist ja mehr oder weniger obsolet, so ähnlich wie local.rc 8)
Ich habe hauptsächlich einen HM-MOD-UART in Betrieb mit VCCU - das ist eine feine Sache mit zwei HM Gateways.
Ich werde mich noch ein wenig in systemd einlesen.
Wenn man für dein Script eine eigene Datei "EnableSCC.service" anlegt - könnte vielleicht klappen. Ich habe allerdings aktuell keine Ahnung, was da noch so drin stehen muss bzw. was die Einträge bedeuten. Vielleicht gibt es Vorlagen:
# /etc/systemd/system/EnableSCC.service
[Service]
Type=oneshot
RemainAfterExit=yes (oder "no"?)
ExecStart=/bin/bash /opt/fhem/EnableSCC.sh
[Install]
WantedBy=multi-user.target
Gab es 1983 schon Linux? ;D
Ganz viele Grüße,
Helmut
Hallo Helmut,
naja der Urknall von der Zeitrechnung in allen Computern ist doch irgendwie 1. Januar 1970, 00:00 Uhr UTC. Seitdem gibt es wahrscheinlich auch sowas (also mit Rest DNA) wie Linux. ;)
Du denkst an einen extra Dienst mit systemd. Das ist sicher der falsche Weg, weil es dann irgendwie entkoppelt wird. Ich meine das Script in ExecStartPre in der systemd Unit fhem.service ist, wenn überhaupt, der sichere Punkt.
Klar man kann eine SCC.service Unit machen und diese aktivieren. Dann muss man im fhem.service eine Abhängigkeit einbauen, das SCC gestartet ist bevor fhem startet. Aber genau das macht ExecStartPre.
Kannst Du nochmal den Weg in #65 von null an durchgehen und testen?
Gruß Otto
Hallo Otto,
bin grade dabei FHEM auf einen RPi 4 mit Buster umzuziehen und habe mit euren Infos 3x SCC + 1x CCD - beides vorher auf aktuellste Firmware geflasht - zum Laufen bekommen.
Ich kann bestätigen, dass dein Weg aus #65 funktioniert.
Danke & frohe Weihnachten!
PS Meine cmdline.txt sieht so aus:
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
Meine config.txt ist leicht anders (kein Core 250 und dtoverlay miniuart-bt):
#SCCs nutzen
dtoverlay=miniuart-bt
enable_uart=1
Hallo Otto,
ja mache ich. Aktuell habe ich allerdings kaum Zeit - Vorbereitungen für's Fest mit der Familie.
Und prima Ergebnis, Szlachta.
Euch erst mal viele Grüße und Frohe Weihnachten!
Helmut
Hallo Szlachta,
danke für die Rückmeldung :)
Wahrscheinlich kann man die Zeile enable_uart=1 auch noch weglassen, die wird vom System intern richtig gesetzt.
Es ist keine leichte Kost, aber zum nachlesen mal noch die offizielle Doku dazu
https://www.raspberrypi.org/documentation/configuration/uart.md
Edit: Allerdings ist es nach meinen Tests falsch die Zeile core_freq=250 wegzulassen. Dann ist die core Frequenz nicht mehr stabil und die miniuart läuft mit wechselnder Frequenz! Das ist, nach allem was ich gelesen habe, falsch!
Man kann das mit drei Zeilen Code und zwei Terminalfenstern einfach nachstellen. Man muss sysbench vorher installieren! In einem Fenster zeigt man die cpu Frequenz an und im anderen startet man den sysbench.
sysbench --test=cpu --num-threads=4 --cpu-max-prime=20000 run
vcgencmd measure_clock arm
vcgencmd measure_clock core
Frohe Weihnachten
Otto
Hallo Otto,
ich habe alles nochmals aufgesetzt.
Es bleibt bei der FM im Syslog, FHEM läuft und der SCC auch:
Dec 23 13:47:49 fhem bash[516]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 23 13:47:49 fhem bash[516]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 23 13:47:49 fhem systemd[1]: Failed to start FHEM Home Automation.
Dec 23 13:47:49 fhem systemd[1]: Started OpenBSD Secure Shell server.
Dec 23 13:47:49 fhem systemd[1]: Reached target Multi-User System.
Dec 23 13:47:49 fhem systemd[1]: Reached target Graphical Interface.
Dec 23 13:47:49 fhem systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Dec 23 13:47:49 fhem systemd[1]: Stopped FHEM Home Automation.
Dec 23 13:47:49 fhem systemd[1]: Starting FHEM Home Automation...
Dec 23 13:47:49 fhem systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
@Szlachta
Könntest du bitte mal die Syslog Ausgabe hier posten?
nano /var/log/syslog
Da der SCC funktioniert könnte es sein, dass bei dir auch eine FM im Syslog steht. Die fällt aber nicht auf.
Gruß Helmut
Hallo,
syslog sieht bei mir wie folgt aus und bringt ebenfalls einen Fehler, SCCs funktionieren...
Dec 23 15:23:54 RPi-FHEM4 bash[606]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 23 15:23:54 RPi-FHEM4 bash[606]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Failed to start FHEM Home Automation.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Started OpenBSD Secure Shell server.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Stopped FHEM Home Automation.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Starting FHEM Home Automation...
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Started Samba NMB Daemon.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Starting Samba SMB Daemon...
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Started Samba SMB Daemon.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Started FHEM Home Automation.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Reached target Multi-User System.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Reached target Graphical Interface.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
@Otto
Ohne die core-Zeile in der config.txt und bei laufendem Sysbench sehen die core Werte stabil aus (1. und letzter Wert jeweils vor/nach sysbench):
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $
Die arm Frequenz ändert sich im Wesentlichen durch das Starten/Beenden von sysbench (1. und letzter Wert sind jeweils vor bzw. nach sysbench-Lauf)
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=600117184
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=600169920
pi@RPi-FHEM4:~ $
sysbench:
pi@RPi-FHEM4:/boot $ sudo sysbench --test=cpu --num-threads=4 --cpu-max-prime=20000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time: 63.3065s
total number of events: 10000
total time taken by event execution: 253.1727
per-request statistics:
min: 24.40ms
avg: 25.32ms
max: 76.00ms
approx. 95 percentile: 25.95ms
Threads fairness:
events (avg/stddev): 2500.0000/25.23
execution time (avg/stddev): 63.2932/0.00
Aha, ok dann macht der PI4 dort etwas anderes als der PI3+. Oder ich habe was falsch gemacht?
Na ich werde nochmal probieren.
Der Text in der PI Dokumentation klingt ja eigentlich so als ob die Firmware selbsttätig alles richtig machen sollte. :)
Aber ich hatte früher andere Informationen und Erkenntnisse :)
Das Mit der Fehlermeldung beim Start prüfe ich auch noch mal. Ich meine wenn alles geht, sind ja zwei Meldungen "akademisch"
Schöne Weihnachten 🎅
Otto
Hallo Otto,
alles prima!
Vielen, vielen Dank und ein schönes Weihnachtsfest!
Helmut
Hi,
Mein Testergebnis:
mit dem overlay miniuart-bt wird die miniuart aktiviert und auf die BT Schnittstelle geschaltet.
Wenn man beim Pi3 nicht die core_freq auf 250 festzurrt, funktioniert die BT Schnittstelle nicht, weil der Takt für die miniUart aus der core_freq abgeleitet wird.
Nachzulesen hier https://www.raspberrypi.org/documentation/configuration/uart.md
Zum Pi4 ist in der oben verlinkten Doku nichts geschrieben. Ich kann es auch nicht evaluieren.
Gruß Otto
Moin,
ich habe mir mal ein FHEM Testsystem aufgebaut :)
Also:
PI4, Buster, core-freq auskommentiert:
# core_freq=250
Zumindest der lepresenced Daemon funktioniert einwandfrei.
Weitere Bluetooth Tests habe ich nicht unternommen
Gruß Helmut
Hallo Helmut,
naja in #75 sah es ja auch so aus, als ob die core_freq beim 4er auf 500 festgezurrt ist von Hause aus.
Bei meinem Test mit dem Pi3 und Pi3+ ging schon der Befehl hcitool dev nicht mehr ;)
Reagiert er überhaupt auf den core_freq=250? Hast Du mal gemessen wie in #75 ?
vcgencmd measure_clock core
Gruß Otto
Hallo Otto,
Mit
core_freq=250
vcgencmd measure_clock core
frequency(1)=250000496
Ohne
# core_freq=250
vcgencmd measure_clock core
frequency(1)=500000992
Der PI4 reagiert, aber auf lepresencede hat das wohl erst mal keinen Einfluss.
Der RSSI Wert liegt bei mir bei -67dB, egal ob mit 250 oder 500 MHz, ich dachte zuerst, die Empfindlichkeit sei reduziert bei 500 MHz.
Ich habe bei meinem Prod-System die core_freq auskommentiert.
Danach hat das System kurz gelaufen - Crash! Ethernet SST.
Bin wieder auf 250 MHz zurück.
Ok :)
Bei deinem Testsystem, also bei deinem Test mit Bluetooth, hattest Du das dtoverlay=miniuart-bt aktiv oder nicht? Nur dann spielt das mit der corefreq ja eine Rolle.
Ich muss nochmal schauen ob ich eine exakte Doku zur miniUART beim Pi4 finde ...
Ja, war gesetzt:
dtoverlay=pi3-miniuart-bt
Habe beim Prod System wieder auf 500 MHz umgestellt.
Ich befürchte ein Spannungsproblem, welches durch die höhere Frequenz eher noch verstärkt wird.
Ich setze das Original 3A PI-Netzteil ein und habe den Eindruck, die Stromversorgung ist schwächer als beim PI2.
Warum?
Mein alte SSD (mit IDE-USB-2 Interface) wird erst gar nicht erkannt, die neue USB-3 SSD läuft nur, wenn der zusätzliche 5V Anschluss am HUB steckt.
der Pi liefert am USB nicht unbedingt freiwillig vollen Strom! config.txt
max_usb_current=1
Leider ist der Link in der config.txt gerade offline? http://rpf.io/configtxt
ich finde dazu aber widersprüchliche Behauptungen - also vielleicht ist das Halbwissen was ich hier erzähle ;)
Der Parameter ist neu für mich.
Habe ich am PI2 nicht gebraucht.
Danke für den Tipp, werde ich testen,
naja Vorsicht! Ich finde den in der Original Doku nicht mehr. Kann sein das es jetzt per default so ist! Dann ist der Parameter nicht funktional.
ich habe die offizielle Doku gefunden: https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md
Dieser Eintrag in der config.txt ist für den Pi 4 obsolet - sorry für die Verwirrung!
Stimmt. Habe ich auch gesucht und einen Eintrag von 2015 gefunden.
Der Parameter galt nur bis zum PI2.
Seltsam, dass damit die alte SSD lief..........
Theorie und Praxis 8) :P :-\ ;)
Hallo zusammen,
ich habe noch etwas getestet.
Mit dem Parameter
core_freq=250
läuft der alte SCC stabiler.
Mit 500 MHz gibt es seitens Homematic schon mal Probleme mit Themen wie
ERR__protocol: CmdDel:1,ResndFail:1
Die treten bei 250 MHz nicht auf.
Gruß Helmut
Hi,
bin gerade dabei, einen RPi4 und CoC v1 mit FHEM einzurichten und auf Eure Diskussion gestoßen.
Da muss ich mal meinen Senf dazu geben 8)
Zitat von: Otto123 am 19 Dezember 2019, 16:02:47
sudo su
echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
Sollte GPIO 18 nicht auch auf 1 gesetzt werden? So war es zumindest in meinem alten Skript und in der Doku von busware (http://busware.de/tiki-print.php?page=COC_Installation_V1 -- Kapitel "Resetting / Booting the COC").
In der Doku zum SCC steht: "LOW level at GPIO18 is used to call the (avr109) bootloader. For normal operation leave it untouched or pull HIGH!". Mein Skript-Vorschlag müsste also beim CoC-v1_1 und beim SCC funktionieren.
Ich hatte auch Probleme (Fehlermeldungen) und folgendes gefunden:
https://elinux.org/RPi_GPIO_Code_Samples#Shell
For operating system versions prior to the raspbian Jessie release, the export and unexport of pins must be done as root. Since the raspbian Jessie release the pi user is a member of the group "gpio" and so control of the GPIO no longer requires a change to the root user.
With Jessie, if using a script as in the code below, you'll need to put a 'sleep 1' command in between your 'export' and 'direction' commands to allow time for the operating system to set up the GPIO number specific direction file. Ein "sudo su" ist also nicht nötig (fhem ist aber in die Gruppe "gpio" aufzunehmen) und ein "sleep 1" müsste noch nach dem "export" rein.
Der Code müsste dann also so ausschauen (das I2C-Interface muss mit raspi-config freigeschaltet sein und die i2c-tools müssen installiert sein, damit die Modell-Erkennung funktioniert):
#!/bin/ksh
MODEL=$(i2cdump -r 0x00-0x1f -y 1 0x50 b | awk -F " " 'NR > 1 { L1=$2; getline; L2=(L1 $2); sub("..$", "", L2); print L2 }')
echo "found extension: ${MODEL}"
echo "resetting 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
sleep 1
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
GPIO access via this legacy sysfs interface has been deprecated since version 4.8 of the Linux kernel (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt).
It will removed from kernel in 2020. The new way of doing GPIO is via the "descriptor-based" character device ABI (Application Binary Interface). You should do a research for Libgpiod (Library General Purpose Input/Output device) and start at https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/
Das kleine Skript müsste dann so ausschauen (Paket gpiod muss vorhanden sein, siehe Infos dazu: https://www.acmesystems.it/gpiod):
#!/bin/ksh
MODEL=$(i2cdump -r 0x00-0x1f -y 1 0x50 b | awk -F " " 'NR > 1 { L1=$2; getline; L2=(L1 $2); sub("..$", "", L2); print L2 }')
echo "found extension: ${MODEL}"
echo "resetting extension..."
gpioset --background --mode=signal `gpiofind "GPIO18"`=1
gpioset --mode=time --sec=1 `gpiofind "GPIO17"`=0
gpioset --background --mode=signal `gpiofind "GPIO17"`=1
sleep 1
Was nicht so schön ist: Änderungen durch gpioset sind nicht persistent. Daher wird der Ausgang gesetzt und gpioset in den Hintergrund geschickt.
Grüße H.
Edit: Skripte getestet und angepasst.
Edit2: Hinweis auf GPIO18 beim SCC. Mein Skript-Vorschlag müsste also beim CoC-v1_1 und beim SCC funktionieren.
Edit3: Im Skript den Modelltyp des CoC/SCC auslesen und anzeigen. Das I2C-Interface muss mit raspi-config freigeschaltet sein und die i2c-tools müssen installiert sein, damit die Modell-Erkennung funktioniert, weil ein String aus dem eeprom ausgelesen wird.
Hallo Herbert,
klingt interessant und richtig - allerdings alles im Konjunktiv :)
Ich habe die Wiki Artikel seinerzeit mit Hilfe einer "Trockenübung" und diesen beiden Threads erneuert :) ich habe selbst die betreffende Hardware nicht.
Am liebsten wäre mir, Du testest das aus und ergänzt das Wiki. Oder ich teste das später mal - habe aber auch keinen Pi4, das ist aber vielleicht nicht relevant.
Gruß Otto
Hi Otto,
Zitat von: Otto123 am 08 Oktober 2020, 19:54:50
klingt interessant und richtig - allerdings alles im Konjunktiv :)
Ich habe die Wiki Artikel seinerzeit mit Hilfe einer "Trockenübung" und diesen beiden Threads erneuert :) ich habe selbst die betreffende Hardware nicht.
Am liebsten wäre mir, Du testest das aus und ergänzt das Wiki. Oder ich teste das später mal - habe aber auch keinen Pi4, das ist aber vielleicht nicht relevant.
ich habe gerade nochmal meine Skripte getestet und daher mein Post angepasst.
Bei mir funktioniert es. Wie aber die Amis sagen: "Your mileage may vary".
Wer selbst testen will: es sollte zumindest buster sein, da ist die Kernel-Version immerhin schon bei 5.4.
Es gibt wohl Verwirrung, welche GPIO anzusteuern sind (GPIO17/18 bzw. nur GPIO17 oder GPIO 22/27). Ich habe jedenfalls die Version, bei dem der CC1101 direkt aufgelötet ist, da muss ich die GPIO17/18 nehmen. Es gibt noch eine Version, bei dem ein PIM-CC1101 aufgesteckt wird und es gibt noch den SCC (siehe Bilder für alle drei im Anhang). Alle nutzen sie den CC1101 von Texas Instruments (https://www.ti.com/lit/ds/symlink/cc1101.pdf).
Das müsste sich doch auslesen lassen?
Ich bekomme :
pi@RPi-FHEM ~ $ sudo i2cdump -y 1 0x50 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 43 4f 43 20 56 31 2e 31 20 52 41 44 49 4f 20 4f COC V1.1 RADIO O
10: 4e 4c 59 20 32 30 31 33 2d 30 31 2d 31 39 0a ff NLY 2013-01-19?.
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................Grüße, H.
Hallo Otto ,
Ich glaube, dass du mir hier auf einigen meiner Baustellen begegnen wirst. Natürlich habe ich auf dem alten raspi einen ssc busware laufen für meine FS20 Komponenten.
Ich habe jetzt etliches gelesen bin mir aber nicht sicher, ob es nun eine anfängertaugliche Anleitung gibt wie sie damals der Hersteller auf seiner Seite hatte, die aber unter Buster nicht mehr geht.
Passt der Code-Schnipsel aus diesem thread von weiter vorne? Nummer finde ich nicht mehr. Die serielle Schnittstelle hatte ich schon bei der Einrichtung einer Bluetooth anwesenheitserkennung umgestellt wie im Wiki bezogen auf miniuart beschrieben ist.
Erneut danke.
Hi,
im Zweifelsfall solltest Du hier (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)) anfangen
Dort gibt es dann einen Link zum passenden Artikel hier im Thread ;)
Gruß Otto
Hallo zusammen,
habe alles Anhand der Anleitung befolgt, leider mit folgenden ergbnis beim start des fhem service:
Failed to start fhem.service: Unit fhem.service failed to load properly: Invalid argument.
See system logs and 'systemctl status fhem.service' for details.
Info: Pi 2 Buster neu aufgesetzt Scc von Busware
Was habe ich falsch gemacht ?
Grüße
Hi,
Du hast einen Fehler in der Datei fhem.service produziert.
Wie sieht die aus? Wie hast Du editiert?
Was steht in /var/log/syslog?
Gruß Otto
die Fehlermeldung schaut wie folgt aus:
pi@raspberrypi:~ $ sudo systemctl start fhem.service
Job for fhem.service failed because the control process exited with error code.
See "systemctl status fhem.service" and "journalctl -xe" for details.
folgendes steht in der Ssyslog:
Feb 17 10:41:59 raspberrypi systemd[1]: Stopped FHEM Home Automation.
Feb 17 10:41:59 raspberrypi systemd[1]: Starting FHEM Home Automation...
Feb 17 10:41:59 raspberrypi bash[506]: /home/pi/SCC.sh: Zeile 1: /sys/class/gpio/export: Keine Berechtigung
Feb 17 10:41:59 raspberrypi bash[506]: /home/pi/SCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Feb 17 10:41:59 raspberrypi bash[506]: /home/pi/SCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 17 10:41:59 raspberrypi systemd[1]: Failed to start FHEM Home Automation.
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 5.
Feb 17 10:41:59 raspberrypi systemd[1]: Stopped FHEM Home Automation.
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Start request repeated too quickly.
Feb 17 10:41:59 raspberrypi systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 17 10:41:59 raspberrypi systemd[1]: Failed to start FHEM Home Automation.
Feb 17 10:42:15 raspberrypi systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
Feb 17 10:42:15 raspberrypi systemd[1]: Timed out waiting for device /dev/serial1.
Feb 17 10:42:15 raspberrypi systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
Feb 17 10:42:15 raspberrypi systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
Feb 17 10:42:15 raspberrypi systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
Feb 17 10:42:15 raspberrypi systemd[1]: Reached target Multi-User System.
Feb 17 10:42:15 raspberrypi systemd[1]: Starting Update UTMP about System Runlevel Changes...
Feb 17 10:42:15 raspberrypi systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Feb 17 10:42:15 raspberrypi systemd[1]: Started Update UTMP about System Runlevel Changes.
Feb 17 10:42:15 raspberrypi systemd[1]: Startup finished in 5.466s (kernel) + 1min 32.041s (userspace) = 1min 37.507s.
Feb 17 10:42:15 raspberrypi systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
Feb 17 10:42:15 raspberrypi systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
Feb 17 10:42:15 raspberrypi systemd[1]: Reached target Multi-User System.
Feb 17 10:42:15 raspberrypi systemd[1]: Starting Update UTMP about System Runlevel Changes...
Feb 17 10:42:15 raspberrypi systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Feb 17 10:42:15 raspberrypi systemd[1]: Started Update UTMP about System Runlevel Changes.
Feb 17 10:42:15 raspberrypi systemd[1]: Startup finished in 5.466s (kernel) + 1min 32.041s (userspace) = 1min 37.507s.
Wobei die Meldung jetzt ganz anders aussieht als Deine Erste!
Gut ohne zu wissen was Du genau getan hast bleibt es ein Ratespiel :'(
Vermutung 1:
ZitatWenn fhem nicht Mitglied der Gruppe gpio ist funktioniert es nicht
Da FHEM jetzt angestartet wird (versucht in Schleife zu starten?) bräuchte man auch die letzten Zeilen im FHEM Log.
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
schwierig, da der Service im Moment nicht läuft, aber folgendes waren die letzten Zeichen:
pi@raspberrypi:~ $ tail -n 20 /opt/fhem/log/fhem-$(date '+%Y-%m').log
2021.02.17 10:38:40 3: CUL_HM set SZ_Fenster statusRequest noArg
2021.02.17 10:38:43 3: CUL_HM set SZ_Licht_L statusRequest noArg
2021.02.17 10:38:44 3: CUL_HM set SZ_Licht_R statusRequest noArg
2021.02.17 10:38:45 3: CUL_HM set SZ_Terrasse_Tuer statusRequest noArg
2021.02.17 10:38:46 3: CUL_HM set Arbeitszimmer_Fenster pct 100
2021.02.17 10:38:46 3: CUL_HM set SchaltaktorFussbodenheizung_Sw_01 statusReques t noArg
2021.02.17 10:38:47 3: CUL_HM set SchaltaktorFussbodenheizung_Sw_02 statusReques t noArg
2021.02.17 10:38:48 3: CUL_HM set SchaltaktorFussbodenheizung_Sw_03 statusReques t noArg
2021.02.17 10:38:49 3: CUL_HM set SchaltaktorFussbodenheizung_Sw_04 statusReques t noArg
2021.02.17 10:38:53 3: CUL_HM set Solarheizung statusRequest noArg
2021.02.17 10:38:53 1: No Logdevice /FileLog_PV/
2021.02.17 10:38:56 3: CUL_HM set WZ_Fenster statusRequest noArg
2021.02.17 10:38:57 3: CUL_HM set WZ_TerrasseFenster statusRequest noArg
2021.02.17 10:38:58 3: CUL_HM set WZ_TerrasseTuer statusRequest noArg
2021.02.17 10:38:59 3: CUL_HM set Wasserpumpe statusRequest noArg
2021.02.17 10:39:06 3: CUL_HM set BWlinks getConfig noArg
2021.02.17 10:39:24 3: CUL_HM set Arbeitszimmer_Fenster getConfig noArg
2021.02.17 10:40:01 3: CUL_HM set BWrechts getConfig noArg
2021.02.17 10:40:19 3: CUL_HM set Bad_Fenster_links getConfig noArg
2021.02.17 10:40:30 0: Server shutdown
ich habe übrignes nach deiner Anleitung gearbeitet (18 Dezember 2019, 09:43:39).
Danke schon mal für deine Unterstützung
Na gut, das sieht nach einem geordneten shutdown aus? :-[
Du meinst den Beitrag? https://forum.fhem.de/index.php/topic,106060.msg1002964.html#msg1002964
Das war aber nicht der Weisheit letzter Schluss!?
groups fhem
Wie sieht die Datei fhem.service aus?
Wie sieht die Datei /home/pi/SCC.sh aus?
Wie hast Du editiert?
fhem.service:
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStartPre=/bin/bash /home/pi/SCC.sh
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
[Install]
WantedBy=multi-user.target
SCC.sh:
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
editiert habe ich über console nano.
Zitat von: Otto123 am 17 Februar 2021, 10:56:17
Wobei die Meldung jetzt ganz anders aussieht als Deine Erste!
Gut ohne zu wissen was Du genau getan hast bleibt es ein Ratespiel :'(
Vermutung 1:
Da FHEM jetzt angestartet wird (versucht in Schleife zu starten?) bräuchte man auch die letzten Zeilen im FHEM Log.
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
was muss ich bei der Gruppe machen ?
Da Du die gefragte Ausgabe von groups fhem nicht zeigen willst - im Zweifel die Gruppe setzen:
sudo usermod -aG gpio fhem
Der fhem Service startet aber jetzt? ???
Ein Traum, Gruppe hinzugefügt und schon geht es!
Velien Dank für deine Unterstützung! :)
Ich hoffe es für Dich. Ich bin noch skeptisch! Ich habe seinerzeit mal die einzelnen Fälle untersucht und als Ergebnis hier im Abschnitt (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Ein_Script_zusammen_mit_FHEM_starten) eine Bemerkung eingefügt.
Ich denke diese gilt, kann also sein, dass es nach einem Systemneustart nicht funktioniert?
gefühlt 10 mal reboot durchgeführt und alles passt :)
Ok danke für das Feedback. Ich verifiziere das bei Gelegenheit nochmal :) aktualisiere das Wiki.
Jetzt noch mal meine Gedanken, die ich mir die letzten 5 Tage machte.
Denn auch bei mir mit Buster und FHEM und einem SCC funktionierte nichts. Habe dahingehend sämtliche Anleitungen hier aus dem Forum, vor allem hier aus dem Thread ausprobiert. Ebenso habe ich die hier genannten Wiki Seiten gelesen.
Aber letztendlich lies der SCC sich nie auf initialized bringenn.
Analog bin ich zu Posting #65 vorgegangen. Exakt danach. Nich mehr und nicht weniger.
Abhilfe hat letztendlich https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file) (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)) geschaffen. Und zwar unter Punkt
1. Script bereitstellen. Dort der letzte Satz/Abschnitt
ZitatDie beiden Zeilen User und Group muss man auskommentieren, da die Unit sonst mit dem User fhem ausgeführt wird.
Achtung: Die Gruppenmitgliedschaft des Users fhem (z.B. gpio) ist beim Systemstart an der Stelle noch nicht wirksam.
Auzukommentieren sind also in der fhem.service Datei:
#User=fhem
#Group=dialout
So habe ich einen laufenden SCC und keine Fehlermeldungen im System.
Nur noch im Fhem log.
[s]2021.03.03 18:36:20 3: SCC: Unknown code A0F2C86102FA2030000000A78E08F0040::-65:SCC, help me!
2021.03.03 18:37:44 3: SCC: Unknown code A0F54861060F8460000000A94DE0E0040::-54:SCC, help me!
2021.03.03 18:38:04 3: SCC: Unknown code A0C99867019B83F00000000EB24::-57.5:SCC, help me!
2021.03.03 18:38:09 3: SCC: Unknown code A0FDC86102FA8790000000AA8E94E0000::-35.5:SCC, help me!
2021.03.03 18:38:24 3: SCC: Unknown code A0B99A25819B83F1B791E0000::-57.5:SCC, help me!
2021.03.03 18:38:24 3: SCC: Unknown code A0E9982021B791E19B83F010100003D::-78:SCC, help me!
2021.03.03 18:38:25 3: SCC: Unknown code A142F845E3238E800000080000000000000000921FF::-60:SCC, help me!
2021.03.03 18:38:32 3: SCC: Unknown code A0FBD861060FAF70000000A70E1110040::-66.5:SCC, help me!
2021.03.03 18:39:23 3: SCC: Unknown code A0F2D86102FA2030000000A78E08F0040::-64.5:SCC, help me!
2021.03.03 18:39:50 3: SCC: Unknown code A0F55861060F8460000000A94DF0E0040::-53.5:SCC, help me!
2021.03.03 18:40:14 3: SCC: Unknown code A0C9A867019B83F00000000EB24::-59:SCC, help me!
2021.03.03 18:40:34 3: SCC: Unknown code A0B9AA25819B83F19AB910000::-57.5:SCC, help me!
2021.03.03 18:40:34 3: SCC: Unknown code A0E9A820219AB9119B83F0101000037::-73.5:SCC, help me!
2021.03.03 18:40:46 3: SCC: Unknown code A1430845E3238E80000008000000000000000091FFF::-58.5:SCC, help me!
2021.03.03 18:41:05 3: SCC: Unknown code A0FBE861060FAF70000000A70E1110040::-65.5:SCC, help me![/s]
Ebenfalls gelöst VCCU ist das Stichwort.
bzw. auch Deine Geräte anlernen, das sind doch Deine HM Geräte oder? VCCU ist auf alle Fälle ein guter Gedanke.
Ja, ganz genau richtig. Das sind die Heizungen.