ASC Rollo Fahrten finden nicht statt

[ch.eick]

Hallo zusammen,
auch mit den letzten Updates kommt es zu Merkwürdigkeiten. Einzelne Rollo Fahrten fallen willkürlich aus und ich weiß jetzt nicht mehr weiter, da es jahrelang sehr gut gelaufen ist.

- FHEM Update hat stattgefunden
- shutdown restart
- kompletter Neustart des RPI hat stattgefunden
- FHEM läuft im Docker Container, der ebenfalls regelmäßig mit updates versorgt wurde
- Verwendet wird TCM mit EnOcean als LAN Device
- Die Position der Antenne wurde bereits testweise verändert
- Die Entfernung der Rollos spielt keine Rolle, da alle problemlos auch über FHEM manuell gefahren werden können
- Das Logging von EnOcean, TCM und EnOcean ist auf verbose 5, der ASC_Debug Modus wurde aktiviert
- Ich habe mal einen ganzen Tag mit allen Fahrten loggen lassen
- Das gefilterte Log File steht hier in der Dropbox
- Die Lists der Devices lege ich ebenfalls mal in die Dropbox

- In diesem Log File wurde leider das Wohnzimmer wegen Lichtwunsch nochmal manuell am Taster rauf/runter gefahren
- WO_W_Rollo_FSB61 hatte keine Fahrt in den privacy Mode, jedoch fuhr es wieder in den night_close
- WO_S_Rollo_FSB61 hatte kein day_open und wurde dann nach dem Aufstehen manuell hoch gefahren 20260407
- KU_S_Rollo_FSB61 hatte kein day_open und wurde dann nach dem Aufstehen manuell hoch gefahren 20260408

Die betroffenen Rollos rollieren willkürlich und auch die Fahrten sind nicht immer die gleichen. Bisher war jedes Rollo bereits mindestens einmal betroffen.

Kann es sein, dass ASC eventuell die Rollos in zu geringem zeitlichen Abstand ansteuert und deshalb das TCM_ESP3_0 Device etwas verschluckt?

EDIT: Zusätzlich ist mir da noch etwas eingefallen. Das WO_S_Rollo_FSB61 hat auch eine Beschattungsfunktion, die auf Position 60 fährt. Das Problem ist, wenn anschließend der privacy Mode auf Position 40 steuert, dann fährt das Rollo nicht etwas nach oben, sondern schließt komplett. Es scheint somit nicht die differenz zur derzeitigen Position zu bestimmen.




Über Tips zu zusätzlichem Debugging oder anderen Ideen würde ich mich freuen. Das Log File kann ich gerne immer wieder aktualisieren.

Falls mal jemand aus dem FHEM Log dinge raus filtern möchte könnte man das so machen. Die zu filternden Zeilen müssen natürlich angepasst werden

Code Auswählen Erweitern

# Beim ersten Aufruf
grep -v -E 'WR_1_Sp|Stromboerse|consumption|: PERL|: eval|DbRep|PV_KI|Standby|WB_|EVU_|Pool|Abfall|MQTT|FS_20|Zirkulation|FB_|Garten|LWP|Shaun|^1|^0|fhem\("set|PDC=|is a single device name' fhem-2026-04-06.log > 20260407_ASC_Debugging.log

# Zum Anhängen weiterer Log Files
grep -v -E 'WR_1_Sp|Stromboerse|consumption|: PERL|: eval|DbRep|PV_KI|Standby|WB_|EVU_|Pool|Abfall|MQTT|FS_20|Zirkulation|FB_|Garten|LWP|Shaun|^1|^0|fhem\("set|PDC=|is a single device name' fhem-2026-04-07.log >> 20260407_ASC_Debugging.log

VG    Christian

[ch.eick]

Moin zusammen,
ich habe jetzt mal mit der Analyse begonnen und die KI gefragt

Code Auswählen Erweitern

Im FHEM ASC fehlen jeden Tag beliebige Fahrten von Rollos.

Auch mit den letzten Updates kommt es zu Merkwürdigkeiten. Einzelne Rollo Fahrten fallen willkürlich aus und ich weiß jetzt nicht mehr weiter, da es jahrelang sehr gut gelaufen ist.

- FHEM Update hat stattgefunden
- shutdown restart
- kompletter Neustart des RPI hat stattgefunden
- FHEM läuft im Docker Container, der ebenfalls regelmäßig mit updates versorgt wurde
- Verwendet wird TCM mit EnOcean als LAN Device
- Die Position der Antenne wurde bereits testweise verändert
- Die Entfernung der Rollos spielt keine Rolle, da alle problemlos auch über FHEM manuell gefahren werden können
- Das Logging von EnOcean, TCM und EnOcean ist auf verbose 5, der ASC_Debug Modus wurde aktiviert

Das heutige Problem: KU_S_Rollo_FSB61 hatte kein day_open und wurde dann nach dem Aufstehen manuell hoch gefahren


ASC Log von diesem Problem:

ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetCmdFn: KU_S_Rollo_FSB61 - Rollo wird gefahren, aktuelle Position: 100, Zielposition: 0. Grund der Fahrt: day open

2026.04.08 06:18:27.052 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
          'endPosition: open'
        ];

2026.04.08 06:18:27.053 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
          'anglePos: 0'
        ];

2026.04.08 06:18:27.054 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
          'position: 0'
        ];


ASC_DEBUG!!! 2026.04.08 06:18:27 - Notify:  ASC_Pos_Reading Event vom Rollo KU_S_Rollo_FSB61 wurde erkannt  - RECEIVED EVENT: $VAR1 = [
          'position: 0'
        ];

ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters:  Fn wurde durch Notify aufgerufen da ASC_Pos_Reading Event erkannt wurde  - RECEIVED EVENT: $VAR1 = 'position: 0';

2026.04.08 06:18:27.055 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'KU_S_Rollo_FSB61_PosValue: 0'
        ];

ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: KU_S_Rollo_FSB61 - Event vom Rollo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von ::gettimeofday: 1775621907 Last Position Timestamp: 1775621907 Drive Up Max Duration: 70 Last Position: 100 aktuelle Position: 0

2026.04.08 06:18:27.056 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'state: day open'
        ];

ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!

ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters:  Fn wurde durlaufen und es sollten Debugausgaben gekommen sein.  !!!Wenn nicht!!! wurde der Event nicht korrekt als Nummerisch erkannt.

2026.04.08 06:18:27.057 3: EnOcean set KU_S_Rollo_FSB61 open
2026.04.08 06:18:27.057 4: EnOcean KU_S_Rollo_FSB61 sent PacketType: 1 RORG: A5 DATA: 015E010A SenderID: FFBA2381 STATUS: 00 ODATA:

ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NICHT versetztes fahren

ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NoDelay: NEIN

2026.04.08 06:18:27.059 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'KU_S_Rollo_FSB61_lastPosValue: 100'
        ];

2026.04.08 06:18:27.059 4: AutoShuttersControl (ASC) - ShuttersCommandSet setDriveCmd wird aufgerufen

ASC_DEBUG!!! 2026.04.08 06:18:27 - FnShuttersCommandSet: KU_S_Rollo_FSB61 - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür

2026.04.08 06:18:27.061 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'KU_S_Rollo_FSB61_nextAstroTimeEvent: 08.04.2026 - 21:41'
        ];

2026.04.08 06:18:27.063 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
          'ASC_Time_PrivacyDriveDown: 08.04.2026 - 18:01'
        ];

2026.04.08 06:18:27.064 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
          'state: created new drive timer'
        ];


Gemini hat gesagt

Die wichtigste Erkenntnis vorab: ASC arbeitet korrekt. Das Modul erkennt die Zeit, berechnet die Zielposition und setzt den Befehl set KU_S_Rollo_FSB61 open ab. Auch FHEM meldet in Zeile 06:18:27.057, dass das EnOcean-Paket (PacketType: 1) versendet wurde.

Das Problem liegt tiefer in der Hardware-Kommunikation oder dem Timing. Hier ist die Analyse der Schwachstellen:
1. Das "Kollisions-Problem" (Hauptverdächtiger)

Im Log steht: ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NICHT versetztes fahren.

Wenn mehrere Rollos gleichzeitig (auf die Sekunde genau) den Befehl zum Öffnen erhalten, feuert FHEM diese Befehle fast zeitgleich an dein EnOcean-LAN-Gateway. EnOcean ist ein sehr langsames Protokoll ohne echte Kollisionsprüfung beim Senden.

    Die Folge: Die Funkwellen überlagern sich, das Gateway "verschluckt" sich oder der Aktor (FSB61) kann das überlagerte Signal nicht dekodieren.

    Lösung: Nutze das Attribut ASC_Shutter_Drive_Stagger im ASC-Hauptdevice. Setze es auf einen Wert wie 5 oder 10 (Sekunden). Dies entzerrt die Fahrten und verhindert Funk-Staus.

2. Die "optimistische" Positionsmeldung

Auffällig ist, dass das Event position: 0 bereits um 06:18:27.054 im Log erscheint, während der eigentliche EnOcean-Sende-Befehl erst um 06:18:27.057 dokumentiert wird.
Das deutet darauf hin, dass das EnOcean-Device in FHEM die Position sofort auf "0" (offen) setzt, sobald der Befehl gesendet wurde, ohne auf eine Rückmeldung vom Aktor zu warten (optimistisches Update).

    Wenn der Funkbefehl den Aktor nie erreicht hat, glaubt FHEM trotzdem, das Rollo sei offen.

    Prüfung: Schau dir im FSB61-Device das Attribut confirm oder die Bestätigungstelegramme an. Sende nur dann ein Statusupdate, wenn der Aktor es quittiert.

3. LAN-Gateway & Docker-Latenz

Du nutzt ein EnOcean LAN-Device im Docker. Hier gibt es eine potenzielle Fehlerquelle im Netzwerkstack:

    TCP-Keepalive: Wenn die Verbindung zwischen Docker/FHEM und dem LAN-Gateway kurzzeitig "schläft" oder abbricht, geht das erste Paket oft ins Leere, bevor die Verbindung neu initialisiert wird.

    Docker-Netzwerk: Läuft der Container im bridge oder host Modus? Für LAN-Gateways ist der host-Modus (oder ein dediziertes Macvlan) deutlich stabiler, um Latenzen bei der Paketweiterleitung zu vermeiden.

4. Hardware-Ermüdung (FSB61)

Die FSB61-Aktoren haben Relais, die nach vielen Jahren der Nutzung "kleben" bleiben können.

    Da du sagst, manuelles Fahren geht problemlos, ist ein mechanischer Defekt unwahrscheinlich, aber: Manuelle Fahrten erfolgen oft einzeln. Die Automatik fährt alle. Das verstärkt das unter Punkt 1 genannte Funk-Kollisionsproblem.

Zusammenfassung & Empfehlung

Um den Fehler einzugrenzen, solltest du folgende Schritte gehen:

    Entzerrung (Sofort-Maßnahme): Setze im ASC-Device attr ASC_Shutter_Drive_Stagger 10. Beobachte, ob die Ausfälle aufhören.

    TCM-Check: Prüfe das TCM-Device. Gibt es im Log Meldungen wie TCM_LAN_Device: disconnected?

    Telegramm-Analyse: Vergleiche bei einer fehlgeschlagenen Fahrt, ob der Aktor überhaupt ein Bestätigungstelegramm schickt. Ein FSB61 schickt normalerweise nach Erhalt des Befehls und nach Ende der Fahrt ein Telegramm. Wenn im FHEM-Log nach dem sent Packet gar kein received Packet vom FSB61 auftaucht, ist das Paket physikalisch nicht angekommen.

    Docker-Netzwerk: Stelle sicher, dass der Container die Kommunikation zum LAN-Gateway ohne große Umwege (NAT) führen kann.

Persönliche Einschätzung: Da es jahrelang lief und nun "willkürlich" passiert, ist eine gestiegene Funklast oder eine leichte Instabilität der Netzwerkverbindung zum LAN-Gateway (eventuell durch Docker-Updates/Kernel-Änderungen) am wahrscheinlichsten. Die Entzerrung der Fahrbefehle (Stagger) löst 90% dieser Probleme bei EnOcean-Systemen.

Meine erste Änderung ist dann jetzt

- attr ASC ASC_ShuttersDriveDelay 5

[CoolTux]

Setze lieber DriiveDelayStart und erhöhe den Wert immer pro Raum.
Also im Schlafzimmer setzt du ihn gar nicht, im Kinderzimmer 1 setzt Du ein Wert von 3 im Kinderzimmer 2 den Wert auf 6 in der Küche auf 9 und so weiter. Also als Beispiel

[ch.eick]

Hmm,
das war bereits gesetzt.
Heute Abend haben alle Privacy Fahrten gefehlt.

Hab jetzt auch mal renewAllTimer gemacht.

[CoolTux]

Gab es denn Änderungen? Andere Rollos, andere Protokolle?

Ändert sich ständig der timestamp vom PosReading? Also pct oder Position.

[ch.eick]

Gab es denn Änderungen? Andere Rollos, andere Protokolle?

Ändert sich ständig der timestamp vom PosReading? Also pct oder Position.

Vor drei Monaten habe ich mal fsb61 ersetzt, das Device im FHEM ist aber geblieben.

Position im EnOcean ändert sich bei jeder Fahrt.

[CoolTux]

Das sich Position bei der Fahrt ändert ist klar. Ändert sich der timestamp des readings auch wenn keine Fahrt ist? Wird also meistens bei Fahrgrund nach ein paar Minuten nach einer Fahrt ein manual angezeigt?

[ch.eick]

Das sich Position bei der Fahrt ändert ist klar. Ändert sich der timestamp des readings auch wenn keine Fahrt ist? Wird also meistens bei Fahrgrund nach ein paar Minuten nach einer Fahrt ein manual angezeigt?

Manual wird nur angezeigt, wenn ich wirklich die Taster verwendet habe. Taster werden momentan nur verwendet, wenn eine Fahrte ausgefallen ist, ansonsten nur wenn es wirklich mal überraschend blendet.

Heute Morgen sind wieder WO_W_ und KU_S_ nicht auf day_open gefahren.
Ich verändere jetzt nochmals die delay Zeiten um einige Sekunden und ich werde den EnOcean Sender mal stromlos machen.
Das die FSB61 jetzt alle defekt sind schließe ich aus, da auch die neuen betroffen sind und manuelles fahren von FHEM aus geht auch.

[CoolTux]

Mach mal zwischen den einzelnen Räumen immer so 5s Verzögerung.

[ch.eick]

Mach mal zwischen den einzelnen Räumen immer so 5s Verzögerung.

okay

Warum das jetzt so passiert ist mir vollkommen unverständlich.
Soll ich mal eine ältere Version von ASV verwenden und dann dabei bleiben, oder gab es da wichtige SW Korrekturen?

[CoolTux]

Da gab es seit 2 Jahren keine relevanten Änderungen

[ch.eick]

Soo,

- CUNx ist von stromlos jetzt neu gestartet
- Alle Rollos haben einen Abstand von 5s
- renewAllTimer

Bei den privacy Zeiten in den Devices gibt es jetzt jedoch immer noch Überschneidungenbei den Minuten.
Kann ich da die exacten Timer irgendwo inklusive Sekunden abfragen?

[CoolTux]

Das sollte soweit passen. Probier am besten erstmal.

[ch.eick]

Das erste Ergebnis...

- Im Wohnzimmer ist WO_S_ und WO_W_ richtig in privacy gefahren, beide Fahrten haben perse unterschiedliche Zeiten dafür.
- Das Rollo im Schlafzimmer war mit privacy wieder korrekt.
- AR_O_ und Schlafzimmer hatten das night_close
- WZ_S_ fehlt night_close
- BA_N_ fehlt night_close
- In der Küche ist KU_S_ nicht in privacy gefahren, was zur Grundzeit mit WO_W_ fahren sollte. Das night_close war wieder richtig.

Morgen suche ich mal die Stellen im Log.