Aktoren schalten nicht nach FHEM Restore

[Desedo]

Hallo zusammen,

aktuell betreibe ich FHEM mit aufgestecktem Enocean-Modul auf einem RPi 2. Im wesentlichen werden damit die Rolladen sowie einige Lampen gesteuert. Ursprünglich ist der RPi mit NOOBS aufgesetzt.

Nun habe ich eine neue SD-Karte mit dem 32-bit Raspbian OS lite (Bullseye) neu erstellt und dort FHEM installiert. Dafür habe ich einen RPi 4 verwendet, damit das produktive System weiter laufen kann.

Die Installation war soweit erfolgreich und FHEM konnte in der Standard-Konfiguration im Webbrowser aufgerufen werden, sowohl auf dem RPi 4 als auch auf dem RPi 2.

Nach dem ich dann ein Backup des produktiven Systems auf die neue SD-Karte kopiert, ein Restore durchgeführt und das neue System heruntergefahren und neu gestarte habe schalten die Aktoren nicht mehr.

Das Enocean-Modul (TCM_ESP_0) ist initialisiert, die Aktoren werden angezeigt und ich kann die Aktionen (opens / closes / stop oder on / off) betätigen, aber es erfolgt keine Reaktion der Aktoren.

Habe momentan keine Idee wonach und wo ich suchen soll und welche Informationen ich liefern kann um dem Fehler auf die Spur zu kommen.

Würde mich sehr freuen, wenn mir hier jemand "auf die Sprünge helfen" könnte.

Danke schonmal und
beste Grüße,

Detlef

[Stelaku]

Hallo Detlef

Ich habe vor kurzen genau das gleiche bei meinen Bruder gemacht, hat ohne Probleme auf anhieb geklapt.  Ich bin da zwar kein Fachmann aber vieleicht ist da was bei Deiner restore Strategie schief gelaufen.

Ich habe bei gestopten FHEM ein backups aus der Konsole heraus gemacht.

Code Auswählen Erweitern


erstrmal fhem stopen

sudo service fhem stop

und dann

sudo tar -C /opt/fhem/ -czf "/home/stephan/FHEM-$(date +%d.%m.%Y_%H%M%S)_$(hostname)_backup.tar.gz" "./"

nicht wundern das dauert ein bischen.


diese backup Datei habe ich dann auf mein neues System geschoben und mit diesen Befehl wieder zurück kopiert

Code Auswählen Erweitern


fhem wieder stoppen

sudo service fhem stop

sudo tar -xvzf FHEM-14.02.2023_170246_Labor_backup.tar.gz -C /opt/fhem/




Fhem wieder starten und es lief auf anhieb.

Vieleicht hilft Dir das ein wenig weiter.

Gruss

Stephan

[Desedo]

Hallo Stephan,

Danke für Dein Feedback.
Mein Vorgehen unterscheidet sich lediglich dadurch, das ich "Backup" aus der FHEM-Oberfläche gestartet habe. Ansonsten war das Vorgehen identisch:
- Backup mit WINSCP von alter SD-Karte auf PC
- Backup mit WINSCP von PC auf neue SD-Karte
- neue SD-Karte in den RPi 2
- FHEM stoppen
- Restore durchführen
- FHEM starten

Hiernach war allerdings das Enocean-Aufsteckmodul (TCM_ESP_0) nicht initialisiert sondern disabled. Hier habe ich FHEM mit shutdown (aus der Web-Oberfläche) gestoppt, dann den RPi 2 ebenfalls herunter gefahren und neu gestartet. Danach war auch das Enocean-Aufsteckmodul initialisiert, aber die Enocean-Aktoren reagieren nicht.
Wenn ich ein Rollo herunterfahre, wird das zwar in der Web-Oberfläche angezeigt, aber anscheinend kein Signal gesendet oder das Signal nicht empfangen.

Läuft bei Dir auch Enocean oder etwas anderes (Zigbee, ZWave, ...)? Vielleicht hängt es ja daran.

Ist Dir vielleicht bekannt ob und wo TAR ein Log-File erstellt?

Beste Grüße,

Detlef

[Stelaku]

Hallo Detlef

Läuft nur EnOcean bei meinen Bruder. Was ich mal bemerkt hatte war das aus einen von fhem aus der Komandozeile durchgeführten backup nicht alles gesichert wird.
Alle Verzeichnisse in /opt/fhem/ die einen Punkt vorangestellt haben werden nicht gesichert. Bin mir nicht sicher ob da vieleicht was für EnOcean mit drinn ist was wichtig ist.

Deshal mache ich meine backups nur aus der Konsole heraus.
Ach und fast vergessen die Rechte des Fhem Verzeichnis eventuelle wieder alle auf fhem setzten falls da was verstellt wurde.


Gruß

Stephan

[Desedo]

Hallo Stephan,

dann werde ich morgen mal neu starten und ein Backup über die Console starten und über das Ergebnis berichten.

Die Rechte muss ich tatsächlich nochmal kontrollieren. Zwischen dem alten OS auf dem RPi 2 und dem neuen OS (Raspbian OS Bullseye) gibt es ja auch den Unterschied hinsichtlich der User. Den User pi gibt es im neuen OS nicht mehr.

Ich habe das Backup-File in mein User-Home-Verzeichnis kopiert und von dort dann den Restore gestartet, aber nachher keine Rechte etc. geprüft.

Beste Grüße,

Detlef

[Johnnyflash]

Hast du daran gedacht, die standardmäßig aktivierte Debug-Ausgabe auf der seriellen Schnittstelle über raspi-config zu deaktivieren?

[Flachzange]

Drei Sachen:
0) Empfängst Du EnOcean-Telegramme?
1) Heißt das TCM-Modul genau so wie vorher oder wurde es umbenannt?
2) Wenn das EnOcean TCM grundsätzlich funktioniert bitte mal prüfen, ob die BaseID noch passt oder diese geändert wurde. Also einmal das Reading baseID abgleichen mit einem Attribut subDef aus einem beliebigen EnOcean-Gerät, was sich nicht schalten lässt.

Edit: Und Logs wären natürlich toll. TCM und EnOcean Device im debug mode.

[Desedo]

Hallo zusammen,

hat nun doch etwas länger gedauert bis ich den Test durchführen konnte.

@Stelaku: Ich habe ein Backup nach Deiner Anleitung durchgeführt. Die Datei ist etwa 1,7 GB groß geworden, ein Backup über die FHEM-Oberfläche ist jedoch nur etwa 50 MB groß.
Nachdem ich dann die neue SD-Karte in den RPi2 gesteckt hatte und das System gestartet habe, war in der FHEM-Oberfläche das TCM-Modul "disabled" (also Stand nach erstem Restore).
Dann habe ich FHEM gestoppt und das Backup "restored". Anschließend habe ich das System "rebooted".

Leider reagieren die Aktoren weiterhin nicht.

@Johnnyflash: Bei der Frage bin ich "lost". Kannst Du mir sagen, wie ich das prüfen kann? Bezieht sich die Frage auf das alte produktive System oder das neue System mit Bullseye?

@Flachzange:
0) Ich habe bei laufendem neuen System einen FT55-Schalter betätigt. In FHEM wird kein Signal empfangen.
1) Ja, Name und Device-Name und die meisten anderen Einträge sind identisch (BaseID, ChipID, FUUID, ...). Es gibt aber auch Unterschiede (siehe Anlagen):
- im produktiven System gibt es unter "Internals" einen Eintrag "FD 11", den gibt es im neuen System nicht.
- im neuen System gibt es unter "Internals" einen Eintrag "DevIoJustClosed 1", den gibt es im produktiven System nicht.
2) Das Attribut subDef ist im produktiven und neuen System identisch. Habe hier den FT55 und den zugehörigen Aktor verglichen. Die BaseID im produktiven und neuen System ist ebenfals identisch.
Logs habe ich (noch) nicht eingeschaltet. Auf welchen Wert soll ich den TCM und Schalter und Aktor stellen?

Beste Grüße,

Detlef

[Nobbynews]

Schon mal die Zuordnung zum Port geprüft?
Schätze mal, das der Stick nicht mehr unter /dev/ttyAMA0 erreichbar ist.
Ich würde die def mal auf by-id umstellen.
Dazu mal ein

Code Auswählen Erweitern

ls -l /dev/serial/by-id
im Terminal eingegeben und die def anpassen.
Z.b. so:

Code Auswählen Erweitern

/dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_200_DC_FT3Y2F8S-if00-port0@57600

[Desedo]

Hallo Nobbynews,

den "ls"-Befehl habe ich mal auf dem produktiven System (im RPi2) und auf dem neuen System (im RPi4) ausführen lassen. In beiden Fällen rerhalte ich die folgende Meldung:

ls: cannot access '/dev/serial/by-id': No such file or directory

Was mache ich falsch?

Beste Grüße,

Detlef

[Flachzange]

ls: cannot access '/dev/serial/by-id': No such file or directory

Was mache ich falsch?

Du führst den Befehl nicht als root / superuser aus.

Mach doch erstmal ein "list" vom TCM device und bitte ein FHEM-log mit der Startsequenz am Anfang. Dann sehen wir doch, was nicht funktioniert.

[Nobbynews]

den "ls"-Befehl habe ich mal auf dem produktiven System (im RPi2) und auf dem neuen System (im RPi4) ausführen lassen. In beiden Fällen rerhalte ich die folgende Meldung:

ls: cannot access '/dev/serial/by-id': No such file or directory

Dann probier' mal so wie Flachzange meinte mit:

Code Auswählen Erweitern

sudo ls -l /dev/serial/by-id

[Desedo]

Hallo zusammen,

@Flachzange und @Nobbynews:
Die Ausführung des ls mit sudo führt zum selben Ergebnis, "ls: cannot access '/dev/serial/by-id': No such file or directory".

Auf der neuen SD-Karte habe ich nun in FHEM "verbose = 5" gesetzt für den TCM, einen FSB61 Aktor und den zugehörigen FT55 Schalter.
Vielleicht noch zur Erläuterung: Alle FT55 Schalter sind in FHEM und im FSB61 eingelernt. Der FT55 schaltet direkt den FSB61, aber FHEM soll das Schalten mitbekommen.

Nach dem Speichern der Änderungen habe ich über die Web-Oberfläche FHEM mit "shutdown" beendet und danach über die Konsole ein "sudo reboot" eingegeben.
Nach dem Neustart des RPi2 waren folgende Einträge im Log-File:

2023.02.18 17:19:05 3: FHEMWEB WEB CSRF error: csrf_317227781252371 ne csrf_757475307208781 for client WEB_192.168.178.53_61542 / command shutdown. For details see the csrfToken FHEMWEB attribute.
2023.02.18 17:19:05 0: Server shutdown
2023.02.18 17:19:07 1: Including fhem.cfg
2023.02.18 17:19:07 3: telnetPort: port 7072 opened
2023.02.18 17:19:08 3: WEB: port 8083 opened
2023.02.18 17:19:08 3: WEBphone: port 8084 opened
2023.02.18 17:19:08 3: WEBtablet: port 8085 opened
2023.02.18 17:19:08 2: eventTypes: loaded 547 lines from ./log/eventTypes.txt
2023.02.18 17:19:08 3: Opening TCM_ESP3_0 device /dev/ttyAMA0
2023.02.18 17:19:08 1: TCM_ESP3_0: Can't open /dev/ttyAMA0: Permission denied
2023.02.18 17:19:10 2: EnOcean Cryptographic functions available.
2023.02.18 17:19:10 2: EnOcean XML functions available.
2023.02.18 17:19:14 1: Including ./log/fhem.save
2023.02.18 17:19:15 1: Messages collected while initializing FHEM:SecurityCheck:
  WEB is not password protected
  telnetPort is not password protected
  WEBtablet is not password protected
  WEBphone is not password protected

Protect this FHEM installation by configuring the allowed device allowed
You can disable this message with attr global motd none

2023.02.18 17:19:15 2: TCM TCM_ESP3_0 not initialized
2023.02.18 17:19:15 1: usb create starting
2023.02.18 17:19:15 1: usb create end
2023.02.18 17:19:15 0: Featurelevel: 6.2
2023.02.18 17:19:15 0: Server started with 120 defined entities (fhem.pl:27110/2023-01-23 perl:5.032001 os:linux user:fhem pid:612)
2023.02.18 17:19:16 2: AttrTemplates: got 257 entries
2023.02.18 17:20:31 0: Server shutdown
2023.02.18 17:20:41 1: Including fhem.cfg
2023.02.18 17:20:41 3: telnetPort: port 7072 opened
2023.02.18 17:20:42 3: WEB: port 8083 opened
2023.02.18 17:20:42 3: WEBphone: port 8084 opened
2023.02.18 17:20:42 3: WEBtablet: port 8085 opened
2023.02.18 17:20:43 2: eventTypes: loaded 547 lines from ./log/eventTypes.txt
2023.02.18 17:20:43 3: Opening TCM_ESP3_0 device /dev/ttyAMA0
2023.02.18 17:20:43 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
2023.02.18 17:20:43 3: TCM_ESP3_0 device opened
2023.02.18 17:20:45 2: EnOcean Cryptographic functions available.
2023.02.18 17:20:45 2: EnOcean XML functions available.
2023.02.18 17:20:49 1: Including ./log/fhem.save
2023.02.18 17:20:50 1: Messages collected while initializing FHEM:SecurityCheck:
  WEBphone is not password protected
  telnetPort is not password protected
  WEBtablet is not password protected
  WEB is not password protected

Protect this FHEM installation by configuring the allowed device allowed
You can disable this message with attr global motd none

2023.02.18 17:20:50 3: TCM TCM_ESP3_0 set reset
2023.02.18 17:20:50 5: TCM TCM_ESP3_0 sent ESP: 550001000570020E
2023.02.18 17:20:50 5: DevIo_SimpleWrite TCM_ESP3_0: 550001000570020E
2023.02.18 17:20:50 1: /dev/ttyAMA0 disconnected, waiting to reappear (TCM_ESP3_0)
2023.02.18 17:20:50 2: TCM TCM_ESP3_0 No response data for set reset
2023.02.18 17:20:50 3: TCM TCM_ESP3_0 set reset
2023.02.18 17:20:50 5: TCM TCM_ESP3_0 sent ESP: 550001000570020E
2023.02.18 17:20:50 5: DevIo_SimpleWrite TCM_ESP3_0: 550001000570020E
2023.02.18 17:20:50 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 get baseID
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500010005700838
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500010005700838
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 get version
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500010005700309
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500010005700309
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 set maturity 01
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500020005CD100150
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500020005CD100150
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 maturity 01 restored
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 set mode 00
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500020005CD1C00AB
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500020005CD1C00AB
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 mode 00 restored
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 set repeater 0000
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500030005A60900003A
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500030005A60900003A
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 repeater 0000 restored
2023.02.18 17:20:51 3: TCM TCM_ESP3_0 set smartAckMailboxMax 0
2023.02.18 17:20:51 5: TCM TCM_ESP3_0 sent ESP: 5500020006C40800A8
2023.02.18 17:20:51 5: DevIo_SimpleWrite TCM_ESP3_0: 5500020006C40800A8
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 No FD
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 smartAckMailboxMax 0 restored
2023.02.18 17:20:51 2: TCM TCM_ESP3_0 initialized
2023.02.18 17:20:51 2: TCM registered transceiver BaseID: FFA8D680 ChipID: 019951AD
2023.02.18 17:20:51 1: usb create starting
2023.02.18 17:20:51 1: usb create end
2023.02.18 17:20:51 0: Featurelevel: 6.2
2023.02.18 17:20:51 0: Server started with 120 defined entities (fhem.pl:27110/2023-01-23 perl:5.032001 os:linux user:fhem pid:442)
2023.02.18 17:26:50 2: AttrTemplates: got 257 entries
---------- "Closes" in Web-Oberfläche beim Aktor gedrückt -----------------------
2023.02.18 17:28:56 3: EnOcean set Rollo_Diele_EG closed
2023.02.18 17:28:56 4: EnOcean Rollo_Diele_EG sent PacketType: 1 RORG: A5 DATA: 00170208 SenderID: FFA8D688 STATUS: 00 ODATA:
2023.02.18 17:28:56 5: TCM TCM_ESP3_0 sent ESP: 55000A000180A500170208FFA8D68800E2
2023.02.18 17:28:56 5: DevIo_SimpleWrite TCM_ESP3_0: 55000A000180A500170208FFA8D68800E2
---------- Automatische Ausführung Steckdosen-Schalter -----------------------
2023.02.18 17:43:34 3: EnOcean set Steckdose1_Diele_UG on
2023.02.18 17:43:34 5: TCM TCM_ESP3_0 sent ESP: 550009070156D2010164FFA8D6810003018B45B1FF00D5
2023.02.18 17:43:34 5: DevIo_SimpleWrite TCM_ESP3_0: 550009070156D2010164FFA8D6810003018B45B1FF00D5

Die Zeilen mit "--- ..." habe ich nachträglich als Kommentar eingefügt. Die Betätigung des Rollos über die Web-Oberfläche erzeugt zwar einen Eintrag im Log (auch beim Aktor), der Aktor schaltet aber nicht.

Log-File Aktor:
---------- "Closes" in Web-Oberfläche beim Aktor gedrückt -----------------------
2023-02-18_17:28:56 Rollo_Diele_EG anglePos: 90
2023-02-18_17:28:56 Rollo_Diele_EG position: 100
2023-02-18_17:28:56 Rollo_Diele_EG endPosition: closed

Bei diesem Test habe ich auch den FT55 betätigt. Dazu sind aber in keinem Log Einträge erzeugt worden. Parallel habe ich auch den FHEM Monitor als separates Fenster geöffnet, aber auch hier hat der FT55 keinen Eintrag erzeugt. Das Rollo lässt sich aber damit steuern.

Ein "list TCM_ESP3_0" habe ich jetzt leider vergessen, kann ich aber morgen nachliefern. Aber vielleicht ist ja aus dem Log schon was zu erkennen?
Auf jeden Fall meinen besten Dank für eure Unterstützung.

Beste Grüße,

Detlef

[Nobbynews]

Die Ausführung des ls mit sudo führt zum selben Ergebnis, "ls: cannot access '/dev/serial/by-id': No such file or directory".

Du hast ein Problem mit Deinem Betriebssystem.
Das steht so auch im Log-File:

2023.02.18 17:19:08 1: TCM_ESP3_0: Can't open /dev/ttyAMA0: Permission denied

Und dann würde ich noch vorschlagen, das Scannen der USB-Ports zu deaktivieren:

2023.02.18 17:19:15 1: usb create starting
2023.02.18 17:19:15 1: usb create end

Und zwar:

Code Auswählen Erweitern

attr initialUsbCheck disable 1

[Stelaku]

Hallo Detlef

Hallo zusammen,

aktuell betreibe ich FHEM mit aufgestecktem Enocean-Modul auf einem RPi 2.

ist es richtig wie Du geschrieben hast, das Du keinen USB Stick sondern ein Aufsteckmodul hast weil dann ist es laut wiki

https://wiki.fhem.de/wiki/EnOcean_Starter_Guide

Wichtig die GPIO-Port auf den Hardware-UART0 umzustellen. siehe hier

der GPIO-Port auf den Hardware-UART0

Gruss

Stephan

[Desedo]

Hallo Stelaku,

ja, ich benutze ein Enocean-Aufsteckmodul, allerdings af einem RPi 2. Die Links finde ich sehr interessant und werde sie mir genauer anschauen, zumal ich evtl. später einen RPi 4 in Betrieb nehmen werde.

Momentan sind meine Aktivitäten aber auf den RPi 2 gerichtet. "Eigentlich" geht es darum, eine jungfreuliche OS-Installation mit Bullseye auf einer neuen SD-Karte für der RPi 2 lauffähig zu machen. Bisher hatte ich das aktuell produktive System auf neue Versionen (Jessie, Buster) hochmigriert.

Die Installation des OS und weiterer Pakete sowie die Grund-Installation FHEM habe ich zwar auf dem RPi 4 gemacht, aber den Restore vom FHEM dann auf dem RPi 2. Damit müsste es eigentlich laufen (hatte ich erwartet  ).

In meinem beigefügten Log (letzter Post) habe ich an zwei Stellen Hinweise zu einem dev/tty/AMA0 Problem gefunden:

2023.02.18 17:19:08 1: TCM_ESP3_0: Can't open /dev/ttyAMA0: Permission denied

und

2023.02.18 17:20:50 1: /dev/ttyAMA0 disconnected, waiting to reappear (TCM_ESP3_0)

Mir fehlen aber die Kenntnisse, was das bedeutet und wie das behoben werden kann oder wo ich suchen kann.
Bin für jeden Hinweis dankbar.

Beste Grüße,

Detlef

[MadMax-FHEM]

Die verlinkten Schritte bzgl. Aufsteckmodul haben nichts mit dem verwendeten PI zu tun, sondern sind Konfigurationen des OS.

Hier meine Notizen zum EnOcean-Aufsteckmodul:

Code Auswählen Erweitern


sudo systemctl disable hciuart
sudo apt purge bluez

sudo nano /boot/config.txt

dtoverlay=disable-bt
enable_uart=1

sudo raspi-config
enable serial

sudo nano /boot/cmdline.txt
remove: 'console=serial0,115200'

define EnOceanPI TCM ESP3 /dev/ttyAMA0@57600


Wenn du BT brauchst, dann nat. BT nicht disablen!
Ob dann weitere Schritte notwendig sind, solte sich in den Links zu finden sein...
EDIT: ganz wichtig! Die Dinge nicht einfach copy/paste in die Console werfen!! Das sind MEINE Notizen, um nichts zu vergessen! Ich prüfe immer, ob es dafür inzwischen neuere Dinge gibt -> Wiki etc.!

Beide Meldungen können kommen weil:

du die Schritte in den Links (enable serial, cmdline.txt, ...) nicht durchgeführt hast -> es kämpfen 2 um den selben seriellen Anschluss (fhem und Console)

fhem nicht zugreifen darf, weil nicht in dialout (dazu ls -la /dev/ttyAMA0 prüfen, ob dort dialout "darf" und der User fhem in dialout drin ist -> sollte aber bei einer Standard-Installation)

initialUsbCheck denkt "der Anschluss gefällt mir, den nehme ich"... -> initialUsbCheck disablen...

Gruß, Joachim

[Desedo]

Hallo zusammen,

der Hinweis und die Anleitung von @MadMax-FHEM habe anscheinend den Durchbruch gebracht. Ob ich seinerzeit bei der Ur-Installation auf dem RPi2 auch etwas am UART gemacht habe, weiß ich echt nicht mehr. Vielleicht gab es da das Problem noch nicht, da der RPi2 ja kein BT hatte.

Ich habe nun anhand der Beschreibung von @MadMax-FHEM und von der Seite https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth meine Konfiguration angepasst. Allerdings wollte ich nicht auf BT generell verzichten. Meine Änderungen waren:

Code Auswählen Erweitern


sudo raspi-config

- Auswahl 3 Interfaces options
- Auswahl I6 Serial Port
- Script = No
- Serial = Yes

sudo nano /boot/cmdline.txt

Hier die folgende Zeile suchen
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

und einen evtl. vorhandenen Eintrag "console=serial0,115200" entfernen, war bei mir aber nicht vorhanden.

Nun den Raspberry auf aktuellen Stand bringen und einen Reboot durchführen:
sudo apt-get update
sudo apt-get upgrade
sudo reboot

Bluetooth auf mini UART legen:
Die Baudrate der mini UART ist abhängig von der System Clock. Hier sind folgende Optionen möglich: force_turbo=1 oder core_freq=250. Bei force_turbo kann es sein, dass die Lebensdauer des RPi reduziert wird, weshalb ich mich für core_freq=250 entschieden habe.

sudo nano /boot/config.txt

dtoverlay=pi3-miniuart-bt
enable_uart=1
core_freq=250

Nun nochmal einen Reboot durchführen:
sudo reboot

und nach dem Neustart prüfen, ob Serial0 auf /dev/ttyAMA0 zugeordnet ist. Dazu folgenden Befehl ausführen:
ls -la /dev



Meine Tests mit dem FT55 und auf der Web-Oberfläche waren positiv, also das Rollo lässt sich damit betätigen. Das System läuft nun mit der neuen SD-Karte und ich beobachte jetzt heute abend und morgen, ob die Automatisierung auch problemlos läuft. Dann melde ich mich nochmal.

Besten Dank nochmal an alle, die hier mit ihrem Knowhow geholfen haben.

Beste Grüße,

Detlef

[Desedo]

Hallo zusammen,

da auch die automatisierte "Nachtverarbeitung" ohne erkennbare Probleme gelaufen ist, werde ich das Thema schliessen.