ACK-Handling von BidCos Nachrichten

[hanoba]

Ich bin vor einigen Tagen von Homematic-CCU1 auf FHEM umgestiegen. Alles hat gut funktioniert, allerdings sind Probleme aufgetreten wenn ich per FHEM (notify) alle meine vier Rollos gleichzeitig geöffnet oder geschlossen habe. Das Öffnen oder Schließen eines einzelnen Rollos hat problemlos funktioniert. Offenbar kommt es zu Problemen, wenn viele Nachricht in kurzer Abfolge gesendet werden.

Nachdem ich den Befehl "sleep 0.6" nach jedem set-Befehl (d.h. nach jeder gesendeten BidCos-Nachricht) eingefügt habe, funktioniert alles.

Nach Analyse des Log-Files (verbose 4) glaube ich folgendes grundsätzliche Problem gefunden zu haben:

Wenn z.B. zwei Nachrichten über BidCos zu senden sind, dann sendet FHEM die Nachricht#2 unmittelbar nach der Nachricht#1 ohne auf ACK#1 von Nachricht#1 zu warten. Hierbei kann das folgende Problem entstehen:
- Beim Homematic-System kann man entweder senden oder empfangen aber nicht beides gleichzeitig (glaube ich zumindest).
- Wenn FHEM Nachricht#2 schickt und gleichzeitig das ACK#1 von Nachricht#1 kommt, dann geht ACK#1 verloren!
- Wenn ACK#1 verloren geht, merkt FHEM dies offenbar erst nach einiger Zeit und sendet dann Nachricht#1 erneut.
- Inzwischen wurde aber bereits Nachricht#2 (und einige weitere Nachrichten) gesendet, d.h. die Reihenfolge der Nachrichten hat sich umgekehrt!
  Wenn z.B. Nachricht#1 eine Lampe (nur ein Beispiel) einschaltet und Nachricht#2 schaltet die Lampe aus, dann ist die Lampe am Ende ein und nicht aus!

Meiner Ansicht nach müsste FHEM die ACKs folgendermaßen behandeln:
- Es wird Nachricht#1 gesendet
- Es wird auf ACK#1 gewartet
- Wenn ACK#1 (nach Timeout) nicht kommt wird Nachricht #1 wiederholt
- Nachricht #2 wird erst dann gesendet, wenn ACK#1 empfangen wurde (oder falls mehrere Wiederholungen von Nachricht#1 fehlschlagen)

Ich bitte um eure Kommentare!

Danke und Gruß

Harald

[hanoba]

Leider hat noch niemand geantwortet...

Ich habe unten noch einen Log der gesendeten und empfangenen BidCos-Nachrichten angehängt, der das Fehlverhalten dokumentiert.

Line 11 (#1): Die nanoCUL (Adresse: 0x133A3C) sendet an den Empfänger (Adresse: 0x360594) eine Nachricht und fordert ein ACK an
Line 12 (#2): Die nanoCul sendet bereits 14ms später eine Nachricht an einen zweiten Empfänger (Adresse: 0x35F481) und wartet NICHT auf das ACK vom ersten Empfänger!

Bei beiden Empfänger handelt es sich um 8fach-Receiver (HM-MOD-Re-8), die bei mir die Rollo-Steuerung übernehmen.

#   LL=Message Length,
#   CC=Message counter,
#   BB=Communication Bit Field  (80 = Message to master, 20 = ACK requested, 04 = Config mode (Broadcast))
#   SSSSSS=Address Sender
#   DDDDDD=Address Receiver
#                                                            LL CC BBTT SSSSSS RRRRRR
   Line 11: 2017.01.08 05:55:26.981 4: CUL_send:  nanoCulAs 0E 06 B011 133A3C 360594 0207000000  #1 
   Line 13: 2017.01.08 05:55:26.995 4: CUL_send:  nanoCulAs 0E 02 B011 133A3C 35F481 0205000000  #2
   Line 16: 2017.01.08 05:55:27.011 4: CUL_send:  nanoCulAs 0E 02 B011 133A3C 35F44E 0205000000
   Line 28: 2017.01.08 05:55:28.269 4: CUL_Parse: nanoCul A 0E 02 8002 35F44E 133A3C 010500000032 -49
   Line 30: 2017.01.08 05:55:28.370 4: CUL_send:  nanoCulAs 0E 03 A011 133A3C 35F44E 0206000000
   Line 31: 2017.01.08 05:55:28.546 4: CUL_Parse: nanoCul A 0E 03 8002 35F44E 133A3C 010600000033 -48.5
   Line 32: 2017.01.08 05:55:28.647 4: CUL_send:  nanoCulAs 0E 04 A011 133A3C 35F44E 0205C80000
   Line 35: 2017.01.08 05:55:28.823 4: CUL_Parse: nanoCul A 0E 04 8002 35F44E 133A3C 0105C8000032 -49
   Line 36: 2017.01.08 05:55:28.923 4: CUL_send:  nanoCulAs 0E 05 A011 133A3C 35F44E 0205C80000
   Line 37: 2017.01.08 05:55:29.099 4: CUL_Parse: nanoCul A 0E 05 8002 35F44E 133A3C 0105C8000032 -49
   Line 38: 2017.01.08 05:55:30.678 4: CUL_HM_Resend: RolloArbeitszimmer nr 2
   Line 39: 2017.01.08 05:55:30.679 4: CUL_send:  nanoCulAs 0E 06 B011 133A3C 360594 0207000000   #3
   Line 40: 2017.01.08 05:55:31.206 4: CUL_Parse: nanoCul A 0E 06 8002 360594 133A3C 01070000000B -68.5
   Line 41: 2017.01.08 05:55:31.307 4: CUL_send:  nanoCulAs 0E 07 A011 133A3C 360594 0207C80000

Gruß

Harald

[vbs]

Meiner Ansicht nach müsste FHEM die ACKs folgendermaßen behandeln:
- Es wird Nachricht#1 gesendet
- Es wird auf ACK#1 gewartet
- Wenn ACK#1 (nach Timeout) nicht kommt wird Nachricht #1 wiederholt
- Nachricht #2 wird erst dann gesendet, wenn ACK#1 empfangen wurde (oder falls mehrere Wiederholungen von Nachricht#1 fehlschlagen)

Hast du bei dir das Attribut "hmLanQlen" gesetzt? Nach meinem Verständnis schickt FHEM nur mehrere Nachrichten parallel raus wenn hmLanQlen > 1 ist. Sprich: Ohne hmLanQlen (bzw. mit einem Wert von 1) sollte das eigentlich wie von dir beschrieben ablaufen. Aber als Warnung: Ich hab eigentlich keine Ahnung.

[hanoba]

Besten Dank für den Tip! Das Attribut "hmLanQlen" gibt es wohl nur für das HMLAN-Modul. Ich verwende aber eine (Selbstbau) CUL. Einen entsprechendes Attribut für das CUL-Modul habe ich in der FHEM-Reference nicht gefunden.

Weiß jemand welchen internen "hmLanQlen-Parameter" das CUL-Modul standardmäßig verwendet?

[frank]

probier die ts_culfw. https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649

[hanoba]

Danke für den Tip! Noch eine Frage dazu: Wird das Warten auf die ACKs von der CUL-Firmware gemacht oder von der FHEM-Perl-SW? Ich dachte es wäre die FHEM-Perl-SW.

[frank]

ich glaube, in dem thread gelesen zu haben, dass diese fw einen moment (400ms?) auf antwort wartet.

[martinp876]

Es wird von der fhem Es auf ein ACK gewartet. Wenn es nicht kommt wird wiederholt. Hmlan geht deutlich besser, da es 3mal wiederholt. Schnell und präzise. Eine cul könnte dies nur in der fw.
Für hm braucht man zwingend eine tscul . Alles andere ist Quatsch - kann man basteln, wird nie stabil.

Wie schon gesagt: ich debuggen die normale cul nicht mehr. Da gibt es nichts zu debuggen. Die kann schlicht das Timing nicht, unbrauchbar. Mit der TS fw ist das eine andere Sache.
Was ist im Einsatz? Die Loge sagen: normale cul. Also umbauen oder selbst sein Glück versuchen .

[hanoba]

Hallo Martin,

recht vielen Dank für deine Antwort!

Ich verwende die "offizielle" culfw auf einem Arduino-Nano wie im Gummibär-Blog beschrieben (http://blog.gummibaer-tech.de/cul-stick-868433-im-selbstbau/).

Wenn ich Dich richtig verstehe, meinst Du mit "umbauen", dass ich ich stattdessen die TSCUL_FW verwenden soll (also keine HW-Änderung). Richtig?
Das hat auch schon Frank vorgeschlagen. Ich werde die TSCUL_FW am Wochenende ausprobieren.

Ich hätte noch zwei weitere Fragen zum besseren Verständnis:

- Ist es richtig, dass ich die aktuelle TSCUL_FW hier finde: https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 ? D.h. es gibt kein GIT-Archiv oder ähnliches?

- Ist mit "es wird von der fhem Es auf ein ACK gewartet" gemeint, dass die FHEM-Perl-SW auf ein ACK wartet (und nicht die CULFW)? Nach meinen Logfiles ist das aber nicht der Fall.

Danke und Gruß

Harald

[MadMax-FHEM]

Ich hätte noch zwei weitere Fragen zum besseren Verständnis:

- Ist es richtig, dass ich die aktuelle TSCUL_FW hier finde: https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 ? D.h. es gibt kein GIT-Archiv oder ähnliches?

Ja, müsste die letzte Version sein.

Hier sind noch ein paar bereits kompilierte Hex-Dateien mit verschiedenen Puffergrößen:

https://forum.fhem.de/index.php/topic,24436.msg536558.html#msg536558

GIT: nicht dass ich wüsste...

Viel Erfolg, Joachim

[hanoba]

Besten Dank für schnelle Antwort!
Gruß Harald

[hanoba]

Ich habe die TSCUL-Firmware inzwischen einen Tag lang ausprobiert bzw versucht, sie fehlerfrei zum Laufen zu bringen. Leider ohne Erfolg. Im Gegenteil: Mit TSCUL funktioniert das Öffnen und Schließen  meiner Rollos nicht mehr zuverlässig. Selbst mit den von mir eingefügten sleep-Befehlen, mit denen die Standard CULFW problemlos läuft (siehe oben), gibt es ständig Fehler. Außerdem zeigt sich mit TSCUL das gleiche fehlerhafte Verhalten, dass nicht auf ein ACK gewartet wird bevor ein neuer Funkbefehl gesendet wird.

Zum dem erzeugten TSCUL-Log-Files hätte ich ein paar Fragen:
- Was bedeutet TSCUL_send und TSCUL_parse genau (siehe Beispiel unten)?
  TSCUL_send:  nanoCul                                           As 0E 3E B011 133A3C 35F481 0205000000
  TSCUL_Parse: nanoCul  139750 A FF13 08120968 01 0E 3E B011 133A3C 35F481 02 _bst _CCAdly:4 -138
- Was ist "139750 A FF13" im Beispiel oben? Timestamp?
- Was bedeuten  "_bst"
- Was bedeutet "_CCAdly:4"
- Was bedeutet: "TSCUL_XmitDlyHM:  nanoCul  id:35F481 dDly:95 toms:33"
- Was bedeutet: "_dhmSt"

Vielleicht kann hier jemand weiterhelfen.

Danke und Gruß

Harald

[MadMax-FHEM]

Die Frage vielleicht besser in dem Thread stellen wo du die TSCUL-FW her hast...
Dort liest der Entwickler mit...
...der müsste ja wissen was was ist...

Gruß, Joachim

[hanoba]

Habe meine Fragen jetzt mal in den TSCUL-Thread gestellt.
Danke und Gruß
Harald