SCC Busware 1101 unter Buster lite nicht mehr zu öffnen

[Sonic]

Otto das stimmt, ich habe dann extra vor 2 Tage einen neuen Pi3 gekauft um mich auch hier zu Verbessern

[Otto123]

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

Code Auswählen Erweitern

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
2. Schritt Script erzeugen

Code Auswählen Erweitern

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
3. Schritt fhem.service ergänzen (nano /etc/systemd/system/fhem.service)
Vor dieser Zeile

Code Auswählen Erweitern

ExecStart=/usr/bin/perl fhem.pl fhem.cfg
diese einfügen

Code Auswählen Erweitern

ExecStartPre=/bin/bash /opt/fhem/EnableSCC.sh

Gruß Otto

[Wzut]

@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.

[Otto123]

Aber genau den Part console=tty1 hat er ja jetzt drin gelassen  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?

[isy]

@Otto: Bin gerade dran, Raspberry Pi 4.

Code Auswählen Erweitern

echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt

Muss es beim PI4 nicht

Code Auswählen Erweitern

echo "dtoverlay=pi4-miniuart-bt" >> /boot/config.txt

lauten?

[Otto123]

Nein, den gibt es nicht.
Ich finde auf https://github.com/raspberrypi/firmware/tree/master/boot/overlays

dies hier:

Name:   pi3-miniuart-bt
Info:   This overlay has been renamed miniuart-bt, keeping pi3-miniuart-bt as
        an alias for backwards compatibility.
Load:   <Deprecated>

Name:   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!

Code Auswählen Erweitern

echo "dtoverlay=miniuart-bt" >> /boot/config.txt

Man 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

[isy]

OK.
Alles so eingerichtet.
Der SCC steckt noch am alten FHEM Server
Mit dem Skript startet FHEM nicht.

Code Auswählen Erweitern

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.

[isy]

Das könnte die Ursache sein:

Code Auswählen Erweitern

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!

[Otto123]

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?

Code Auswählen Erweitern

sudo su
echo 17 > /sys/class/gpio/export

[isy]

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!

Code Auswählen Erweitern

Dec 19 15:22:59 fhem kernel: [ 1342.960660] Bluetooth: hci0: advertising data len corrected

Code Auswählen Erweitern

nano /etc/rsyslog.d/01-blocklist.conf
:msg,contains,"Bluetooth: hci0: advertising data len corrected" ~

[Otto123]

und ein

Code Auswählen Erweitern

ls -lha /sys/class/gpio

[isy]

Code Auswählen Erweitern

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#

[Otto123]

und der Rest?

Code Auswählen Erweitern

echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value

Mir fällt was auf:
mach mal

Code Auswählen Erweitern

usermod -aG gpio fhem
Wird der Inhalt von fhem.service dann schon als fhem ausgeführt?

[isy]

Code Auswählen Erweitern

root@fhem:/home/pi# echo out > /sys/class/gpio/gpio17/direction
bash: /sys/class/gpio/gpio17/direction: Datei oder Verzeichnis nicht gefunden

und

Code Auswählen Erweitern

root@fhem:/home/pi# echo 1 > /sys/class/gpio/gpio17/value
bash: /sys/class/gpio/gpio17/value: Datei oder Verzeichnis nicht gefunden

Code Auswählen Erweitern

usermod -aG gpio fhem
Deine Frage verstehe leider ich nicht. Nach Eingabe dieses Befehls passiert nichts auf der Konsole.

[isy]

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.