Sonntag, 17. Juli 2016

Raspberry Pi HomeMatic-Modul

Für die Himbeere gibt es seit einiger Zeit eine Homematic Modul HM-MOD-RPI-PCB. Der Bausatz ist simpel aufgebaut, es ist nur eine Buchsenleiste und zwei Platinen mit Pfostenverbinder zusammenlöten.
Der HM-CFG-USB Adapter ist schon nicht mehr lieferbar, den HM-CFG-LAN soll es bald nicht mehr geben. Damit wird diese Modul und die Implementierung in FHEM zunehmend interessant!

Seit 18.7.2016 ist das Modul direkt in FHEM und das CUL_HM Modul ist angepasst. Damit ist die Installation schon einen Schritt einfacher.

Es gibt einen Thread der alles beschreibt, im Wiki findet man zunehemend entsprechende Infos.
Ich schreibe mal wieder auf wie es bei mir funktioniert hat:

Zutaten:
  • Raspberry PI B, B+, B2 oder B3
  • Image Jessie-Lite vom 27.05.2016 oder aktueller
  • System Grundkonfiguration: Zeitzone, Hostname, Kamera etc...

Serielle Schnittstelle vorbereiten:

Die folgenden Schritte kann man vor dem ersten Start auf der SD Karte (nach dem Image schreiben) ausführen oder aber nach dem ersten Start im Terminal.
  • In der Datei /boot/cmdline.txt diesen Eintrag löschen: console=serial0,115200 
  • Die Datei /boot/config.txt um diese Zeile ergänzen: enable_uart=1 
  • Bei dem PI 3 muss die UART und die miniUART getauscht werden. Die Datei /boot/config.txt insgesamt um diese Zeilen ergänzen:
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
Statt core_freq kann man auch force_turbo=1 gesetzt werden. Wichtig ist hierbei, dass dei Taktfrequenz konstant bleibt.

Nach dem ersten Start den serial-getty Dienst deaktivieren:
sudo systemctl disable serial-getty@ttyAMA0.service

Jetzt unbedingt neu starten!

Zusammenfassung

Falls man die Dateien im Image nicht vor dem ersten Start manipuliert hat, also nach dem ersten Start im Terminal:
sudo su
echo "enable_uart=1" >> /boot/config.txt 
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt # Nur beim Pi3 notwendig
echo "core_freq=250" >> /boot/config.txt 
sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service
reboot
In jedem Fall braucht man einen Neustart. man kann also die obigen Zeilen auch in das Script zur Grundkonfiguration des raspberry einbinden und läuft nicht Gefahr die Dateien im /boot durch den falschen Windows Editor unbrauchbar zumachen.

Setup von FHEM

Ganz nach persönlicher Vorliebe!
Interessant ist auf alle Fälle das Script von Betateilchen. Allerdings installiert dies die SVN Version. Der normaler User sollte in Standard Setup verwenden.

Beim PI 3 wegen Timingproblemen muss man noch eventuell die /etc/init.d/fhem um sleep 10 am Anfang ergänzen

Nach Neustart in FHEM einfach die Definition
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx

Firmware flashen

Das frische Modul sollte noch mit neuer Firmware geflasht werden, die Originalversion war 1.2.1 empfohlen ist derzeit die 1.4.1 von eq3.
Laut Wiki  ist jetzt auch das flashen der Firmware von FHEM aus möglich.
Einfach mit ssh am Pi anmelden und dann:

wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/

Anschließend in der Oberfläche diesen Befehl eingeben und warten bis das Modul sich wieder meldet.

set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3

Falls das nicht funktioniert, hier noch die händische Methode:
Am Besten FHEM beenden, damit keine Zugriffe auf das Modul erfolgen!

sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

Bei der letzten Zeile kamen mehrere Fehler. Ich habe es einfach mehrfach wiederholt und irgendwann ging es.

Sollten beim Firmwareupdate hartnäckig Fehler auftreten (oder einfach nichts passieren) muss das Modul mal vom Strom getrennt werden, neustart reicht nicht!

Hintergrundinformationen 

Man kann die Grundkonfiguration mit raspi-config machen:
  • Zeitzone
  • Hostnamen ändern
  • Kamera aktivieren
  • Serielle Schnittstelle aktivieren
  • usw.
Das raspi-config Tool ändert immer mal seinen Aufbau, ich will das deshalb hier nicht bildlich beschreiben.
Man kann aber auch alles per Script machen:
# Zeitzone
echo "Europe/Berlin" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata
#Hostname noch testen!!!
hostname -b raspib
sed -i s/raspberrypi/raspib/ /etc/hosts
nano /etc/init.d/hostname.sh
nano /etc/hostname
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
#Kamera
echo "start_x=1" >> /boot/config.txt
echo "gpu_mem=128" >> /boot/config.txt
echo "disable_camera_led=1" >> /boot/config.txt
Achtung: Scripte immer unbedingt im Unix Code (nur LF) abspeichern!!!

Die Sache mit den Rechten auf /dev/ttyAMA0

Der Start des Dienstes serial-getty@ttyAMA0.service setzt offenbar die Rechte auf.
crw--w---- 1 root tty 204, 64 Jul 15 20:36 /dev/ttyAMA0
Ein Beenden des Dienstes ändert daran nichts.

Wird der Dienst nicht gestartet stehend die Rechte auf
crw-rw---- 1 root dialout 204, 64 Jul 18 09:51 /dev/ttyAMA0

So müssen die Rechte auch aussehen! Und der User fhem muss in der Gruppe dialout sein!

Die Sache mit dem Dienst serial-getty@ttyAMA0.service

Ein systemctl disable serial-getty@ttyAMA0.service verhindert zwar den automatischen Start aber nicht den manuellen Start bzw. den Start durch andere Prozesse. Erst der Befehl systemctl mask xxx verhindert jeglichen Start.

Der Eintrag console=serial0,115200 in der /boot/cmdline.txt ist offenbar dafür verantwortlich, dass der Dienst trotz disable gestartet wird. Löscht man diesen Eintrag, wird der Dienst auch nicht gestartet. Unterm Strich kann man den Start des Dienstes auf zwei Arten verhindern:
sudo sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
sudo systemctl disable serial-getty@ttyAMA0.service
oder
sudo su
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
chmod g=rw /dev/ttyAMA0

Eigentlich würde ich ein systemctl mask serial-getty@ttyAMA0.service bevorzugen um den Dienst generell auszuschließen.

Wenn Bluetooth beim Pi 3 funktionieren soll: ttyAMA0 und ttyS0 tauschen

Der Eintrag dtoverlay=pi3-miniuart-bt in der Datei /boot/config.txt sorgt dafür, dass die Ansteuerung des BT Moduls jeweils über den Alias serial1 erfolgt.
Eine Änderung wie früher beschrieben in der Datei /lib/systemd/system/hciuart.service ist nicht mehr notwendig!

Im laufenden Betrieb kann  man auch so vorgehen
sed -i s/ttyAMA0/ttyS0/ /lib/systemd/system/hciuart.service
daemon reload
systemctl restart hciuart

Man kann die korrekte Ansteuerung mit ls -l /dev/ser* überprüfen:
Mit dtoverlay=pi3-miniuart-bt (BT an ttyS0)
lrwxrwxrwx 1 root root 7 Jan  1 18:48 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan  1 18:48 /dev/serial1 -> ttyS0

Ohne dtoverlay=pi3-miniuart-bt (BT an ttyAMA0)
lrwxrwxrwx 1 root root 5 Jan  1 19:02 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jan  1 19:02 /dev/serial1 -> ttyAMA0

Alternativ könnte man BT deaktivieren.

FHEM Setup

Die Einbindung in FHEM passiert mit dem Modul HMUARTLGW. Das HM-MOD-RPI-PCB hat einen eigene hmId.
define HMUART1 HMUARTLGW /dev/ttyAMA0

Im praktischen Betrieb muss man aber die eigene hmId setzen. Ohne das Attribute hmId empfängt das Modul scheinbar nichts.

attr HMUART1 hmId xxxxxx

Das attr qLen spielte bei mir nach einiger Zeit eine Rolle (Meldung im Log: queue is full, dropping packet), ich habe den Wert auf 60 gesetzt.

Um AES-CBC  nutzen zu können (Rauchmelder SD-2) muss das Paket libcrypt-rijndael-perl installiert werden.

Das UART Modul merkt sich die hmId und die AES Schlüssel bis zur nächsten Änderung.
Das Modul HMUARTLGW unterstützt auch die Remoteanbindung des Raspberry mit socat. Näheres siehe Commandref.

Probleme

FHEM startet mit knapp 100% CPU wenn das HM-MOD-RPI-PCB Modul einfach gesteckt wird.
Es hilft wenn man vor dem Stecken die Erkennung von FHEM ausschaltet.
attr initialUsbCheck disable 1

oder unmittelbar nach der Neuinstallation!
echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfg

Notizen

Eventuell braucht man mit der original Firmware (1.2.1) noch das:
echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value

Damit wird das Reset Pin am Modul definiert gesetzt

Kommentare:

  1. Super Beitrag. Habe den Teil mit dem alternativen Flashen ins FHEM Wiki übernommen. VG

    https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

    AntwortenLöschen
  2. Hallo,
    Vielen Dank für den informativen Beitrag!
    Eine Frage habe ich noch: Du schreibst "Raspberry PI B, B+, B2 oder B3".

    ich habe einen Raspberry Pi Model B, 512MB RAM (Rev. 2.0), das sollte ja danach eigentlich passen.

    Im ELV-Shop steht allerdings nur "Kompatibel mit Raspberry 2B und 3". Kannst du bestätigen, dass es auch mit dem Model B (ohne 2) funktioniert?
    Danke und LG
    Michael

    AntwortenLöschen
    Antworten
    1. Hallo Michael,
      ehrlich gesagt war ich immer davon ausgegangen, das es nur auf die GPIO ankommt.
      Ich habe es gerade getestet, funktioniert unter FHEM auf einem Pi B. Ich vermute die Aussage von ELV trifft auf die Kombination RPI Modul & OCCU-SDK (Software) zu. Ich vermute die Software braucht den Pi 2.
      Ich übernehme keine Garantie dafür, dass es läuft. Aber ich wüsste nicht warum es nicht laufen sollte.
      Gruß Otto

      Löschen
    2. Moin moin,
      super, vielen Dank! Dann werde ich mir das Ding jetzt bestellen und mal mit meinem alten Pi B ausprobieren. Will es ja sowieso direkt mit FHEM nutzen, wie hier beschrieben. Wenn du einen Reflink oder die Kundenwerbung für ELV oder so am Start hast, bestelle ich auch gerne darüber ;-)

      Löschen
  3. Hallo Otto,
    vielen Dank für Deinen super Beitrag! Der hat mich ein großes Stück vorwärts gebracht.

    Ich stehe jetzt aber gerade vor einem Problem, welche mich langsam aber sicher verzweifeln lässt...
    Beim Versuch die neue Firmware auf das Modul zu laden hört der Vorgang nach spätestens 5 Sekunden auf oder bleibt direkt beim starten stehen.
    Was mir noch auf gefallen ist, ist das ich bei mir kein serial1 habe, wenn ich ls -l /dev/ser* ausführe.

    Hast Du eine Idee an der es liegen kann? Für jede Hilfe wäre ich sehr dankbar!

    VG Marcel

    AntwortenLöschen
    Antworten
    1. Hallo Marcel, die Geräte serial1 und serial0 gibt es nicht bei allen Systemversionen. Also bei wheezy und jessie vor Mai 2016 ist das glaube ich normal. Schau ob Du ttyS0 hast.
      Wegen dem flashen, schau mal ob der Hinweis ganz am Ende hilft (gpio setzen).
      Mehrfach versuchen, Modul mal vom Strom trennen.
      Gruß Otto

      Löschen
    2. ttyS0 wird mir auch nicht angezeigt. Er zeigt mir tty, tty0 - tty63, ttyAMA0 und ttyprintk an. Wofür genau ist das ttyS0? Und kann das der Grund sein, warum das flashen immer fehlschlägt?
      Das setzen der GPIOs hab ich auch gerade noch ausprobiert. Leider keine Veränderung. Habe schon gefühlte 100 mal den Vorgang widerholt. Dann komplett abgeschaltet. Stromlos gemacht. Und das ganze wieder von vorne.
      In FHEM steht auch folgendes im Log: HMUARTLGW myHmUART application switch failed, application-firmware probably corrupted!

      Ist es evtl. auch möglich das mein Modul defekt ist?

      VG Marcel

      Löschen
  4. In 'Serielle Schnittstelle vorbereiten:', 'Zusammenfassung' muß es heißen:
    ---
    echo "enable_uart=1" >> /boot/config.txt
    echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt # Nur beim Pi3 notwendig
    echo "core_freq=250" >> /boot/config.txt
    ---

    AntwortenLöschen
    Antworten
    1. Danke :) - hier lag die Quelle des Fehlers. Habe gleich noch eine weitere Stelle korrigiert.

      Löschen
  5. Danke für die Anleitung. Ich habe Raspi Model B mit Jessie lite.
    Wenn man diese parallel zum Wiki verwendet stellen sich mir 2 Fragen:
    1. Muss in /etc/inittab die Zeile
    T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
    auskommentiert werden
    2. Wie soll die Zeile in /boot/cmdline.txt aussehen?
    Muss der Eintrag kgdboc=ttyAMA0,115200 auch gelöscht werden?
    dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait

    AntwortenLöschen
    Antworten
    1. Bitte alle Artikel genau lesen! Hier steht nichts anderes wie im Wiki. Die Zeile in der inittab ist nur für wheezy relevant, auf meinem jessie existiert diese Datei nicht. Meines Wissen existiert diese nicht mehr in Jessie. Ich sage explizit nichts darüber wie die Datei /boot/cmdline.txt aussehen muss, das ist individuell. Bei meinem Jessie existiert kein Eintrag mit kgboc... Da er aber wie console=... eine Verbindung zur Schnittstelle ttyAMA0 herstellen würde, würde ich ihn entfernen!

      Löschen
  6. toller Beitrag danke.
    Aber ich habe das Problem, dass bei meinem Raspberry 3 entweder WIFI oder HM-MOD-RPI-PCB funktioniert;d.h. wenn ich nur über WIFI auf den R3 zugreife, läuft HM-MOD-RPI-PCB nicht; aber wenn ich ein LAN-Kabel einstecken und reboote, dann funktioniert HM-MOD-RPI-PCB.
    Hast du ev. Vorschläge was ich hier falsch mache?

    AntwortenLöschen
    Antworten
    1. Sorry, da kann ich Dir nicht helfen. Ich sehe da keinen Zusammenhang, habe das aber auch nicht probiert.

      Gruß Otto

      Löschen
  7. Hi Otto, das ist eine klasse Anleitung, weil jeder Schritt sehr gut erklärt ist, was für Linux-Anfänger wirklich unerlässlich ist - hat man nicht immer :-)

    Ich habe hier das Steckmodul HM-MOD-RPI-PCB auf einen Raspi B gesteckt, um es parallel mit einem LAN Gateway (HM-LGW-O-TW-W-EU-2) zu betreiben und somit Homematic IP-Geräte ansprechen zu können. Die beiden Geräte koexistieren bereits in fhem, ein mitlaufendes FileLog zeigt allerdings andauernd Events wie "UNKNOWNCODE A0A8A800200100056C8B500::-21:HW_DEVICE2".

    Eine über das Steckmodul angelernte Funksteckdose kann nun problemlos über das neue Modul erkannt und geschaltet werden, nur wie jetzt ein Homematic IP-Gerät angelernt wird, ist mir völlig unklar. War da zuviel Wunschdenken bei mir vorhanden und das geht gar nicht? Oder fehlt noch etwas? Ich habe nirgends einen Hinweis dazu gefunden und bin für jeden Hinweis dankbar!

    TIA Chris

    AntwortenLöschen
    Antworten
    1. Ooops, das war nicht ganz vollständig erklärt, die angelernte Funksteckdose ist natürlich noch ein Homematic-Gerät ;-)

      Löschen
    2. Du kannst auf dem Pi mit der entsprechende Software eine CCU2 emulieren. Die kann auch IP Geräte, FHEM kann das nicht. Es gibt auch Projekte die auf dem Pi eine CCU2 und FHEM parallel laufen lassen - YAHM - Yet Another Homematic Management. Aber trotzdem kann das Modul dann nur eine der beiden Welten bedienen. Eine CCU2 kann mit HMCCU in FHEM abgebildet werden, eine echte Integration ist das nicht.
      Es zu diesen Themen dutzende Artikel im FHEM Forum.
      Die UNKNOWNCODE Meldung kommt eventuell von Deinen HM-IP Geräten.
      Gruß Otto

      Löschen
    3. Vielen Dank für diesen Hinweis, der Zusammenhang mit anderen Lösungen war mir nicht klar - werde mir also mal YAHM ansehen. Die Trennung der beiden Welten ist schon klar, so war es ja auch gedacht. Thnx Chris

      Löschen
  8. Hallo Otto,

    klasse Anleitung! Flashen hat erst nach dem Überbrücken von J1 funktioniert.
    Nun zwiet mir FHEm an,dass myHmUART den STatus opened hat.

    Auszug aus meiner fhem.cfg:
    define myHmUART HMUARTLGW /dev/ttyAMA0
    attr myHmUART devStateIcon .*:hm_ccu
    attr myHmUART hmId 082965
    attr myHmUART logIDs sys,all
    attr myHmUART room System

    Meine Fage:
    Was muss ich tun, damit mir die CCU im WebGUI angezeigt wird? Dann müsste ich die angelernte HM-Wetterstation doch auch mit der dafür vorgesehenen iPhone-App sehen???
    Ist aber beides nicht der Fall.

    Beste Grüße von der Ostsee

    Christian

    AntwortenLöschen
    Antworten
    1. Hallo Christian,

      sorry aber ich will nicht und ich werde hier nicht ein Supportforum betreiben. Bitte stelle die Frage im FHEM Forum, wobei ich sie ehrlich gesagt nicht verstehe, also drücke dies "CCU im WebGUI " dort präziser aus.

      Gruß Otto

      Löschen
  9. Der Kommentar wurde von einem Blog-Administrator entfernt.

    AntwortenLöschen
    Antworten
    1. Hallo Christian,

      sorry aber ich will nicht und ich werde hier nicht ein Supportforum betreiben. Fragen und Kritiken die im direkten Zusammenhang zu meinen Beiträgen stehen beantworte ich gerne - aber das geht eindeutig weiter. Also bitte stelle diese Frage im FHEM Support Forum.
      Bitte hab auch Verständnis dass ich dieses lange Log wieder lösche, das hat hier nichts zu suchen.

      Gruß Otto

      Löschen
    2. Dieser Kommentar wurde vom Autor entfernt.

      Löschen
    3. Irgendwie hat es die letzte Frage von Chris gelöscht ohne das ich dies wollte. Also nochmal mein Stand zu HM-IP
      Man kann eine CCU2 in FHEM mit dem Modul HMCCU abbilden. Das ist aber eine völlig andere Sache, als wenn FHEM die Zentrale ist. Für mich käme diese Variante nicht in Frage. Sie ist für mich eine Krücke!
      Mit dem hier besprochenen Modul kann man quasi mit verschiedener Software eine CCU2 bauen, das war nicht Inhalt meines Artikels. In der Qualität wie FHEM Zentrale für Homematic sein kann, geht das nicht für Homematic-IP! Eine "saubere" Integration beider Homematic Welten in FHEM gibt es derzeit nicht. Man kann mit beiden was machen, aber auf völlig unterschiedlichem Level.
      Gruß Otto

      Löschen
  10. Hi Otto,
    super Anleitung!! Leider stehe ich vor einem Problem und sehe so langsam den Wald vor lauter Bäumen nicht mehr.
    Ich verwende einen RPI3 mit Stretch.
    Mittlerweile habe ich alles oben beschriebene sowie noch einiges mehr getestet, leider ohne Erfolg.
    ls -l /dev/ser* wirft mir lediglich serial1 -> ttyS0 aus. Serial0 gibt es bei mir nicht.
    Könntest du mir evtl. behilflich sein?

    AntwortenLöschen
    Antworten
    1. Habe es gelößt bekommen, hatte noch einen pivccu overlay eintrag in der boot/config.txt

      Löschen
  11. Hallo Otto,
    Danke für die Anleitung. Zu welchem Zeitpunkt wird das Modul auf die GPIO Ports aufgesteckt? Ich habe in der boot config wlan und bluetooth abgeschaltet per
    dtoverlay=pi3-disable-wifi
    dtoverlay=pi3-disable-bt
    muss ich BT wieder aktivieren? Dankeschön

    AntwortenLöschen
    Antworten
    1. Hallo,
      es ist völlig egal zu welchem Zeitpunkt Du das Modul steckst. Ich würde vermeiden es im laufenden Betrieb zu tun.
      Es ist meines Wissens egal ob Du BT abgeschaltet hast. Ob es dann trotzdem ohne den Eintrag
      dtoverlay=pi3-miniuart-bt
      geht, habe ich nicht probiert. Ich denke aber nicht, da damit die Zuordnung der UART und miniUART getauscht wird. Meines Wissens funktioniert das Modul nur mit der UART.
      Gruß Otto

      Löschen
  12. Hallo,
    vielen Dank für die tolle Anleitung, leider steht bei mir immer, dass es disconnected ist. Ich kann auch nichts über die Konsole verändern. Ich melde mich über Putty und als Benutzer root mit meinem Passwort an, aber sobald ich einen Befehl eingebe kommt die Meldung
    -sh: sudo: not found
    ich hoffe du kannst mir helfen. Lieben Gruß Marcel

    AntwortenLöschen
    Antworten
    1. Hallo Marcel,
      wenn Du als root angemeldet bist brauchst Du kein sudo. Allerdings wird das nichts mit dem Problem disconnected zu tun haben. Ich kann hier aber kein Supportforum betreiben. Vielleicht stellst Du Dein Problem im FHEM Forum ein.
      Gruß Otto

      Löschen
  13. Hallo och habe das Problem den 5v pin freizu halt und bin auch neu in dem ganzen thema (noch in Vorbereitung usw) und würde das modul gerne beim pi3 auf den pin 17 stecken geht das? Möchte fhem verwenden (sobal ich das ding mal endlich sauber aufgesetzt bekommnit der neusten version vom rasbian scretch und +blauzahn und wifi) was müste ich dann ändern oder ist das bei egal welcher instalart die sache mit dem socc
    Liebe Grüße leo dank im vorraus
    (Und das mit dem umtauschen von dtoverlayfür bt /wifi ist soweit schon sinnig angekommen)

    AntwortenLöschen