MISSING ACKs ohne Ende bei TCs und VDs

[wkarl]

Hallo,

Seit cirka zwei Wochen treten vermehrt MISSING ACKs auf. Es ist leider für mich nicht rekonstruierbar, da es immer wieder bei allen TCs und VDs auf tritt. Gefühlt mehr bei den VDs.
Nachdem ich im Forum gelesen habe, dass eine RSSI-Wert zwischen 40 und 70 gute Ergebnisse liefert (meine waren meist über 60/70), habe ich heute alle TCs und VDs vom CUL_868 (Keller) zum CUNO_01 (Ergeschoss) umdefiniert. Die Werte sind nun um ca 20 verbessert, aber der Zustand bzgl MISSING ACK ist nicht viel besser geworden.
Hat jemand eine Idee wie ich das Problem weiter einkreisen kann, um die Ursache zu finden?
Danke schon mal
walter

[martinp876]

Hallo Walter,

Bist du auf der letzten Version? in 2376 habe ich einen Bug entfernt...

andernfalls:

Wie haeufig treten die missing-acks auf? Du musst wohl logs ziehen. Dazu ist es sinnvoll die Parameter zu setzen
attr global mseclog 1
attr global verbose 1
attr <cul> hmProtocolEvents 1
attr <cul> loglevel 1

Dann laufen lassen und ein paar missing-acks abwarten

Gruss
Martin

[wkarl]

Hallo Martin,

hier die log Informationen.

ciao walter

[martinp876]

Hallo Walter,

die logs muss ich noch durchsehen. Aber aufgefallen ist gleich, dass du hmProtocolEvents eingeschalten hast. Kannst du dies ausschalten oder löschen? Es führt in zeitkritischen Ablaeufen immer wieder timing problemen. Ich warne regelmaessig davor...

Falls es dann immer noch auftritt, noch einmal melden

Gruss
Martin

[wkarl]

Hallo Martin,

im fhem.cfg sind die Einträge auf 0_off gesetzt. Trotzdem trotzdem gibt es gehäuft MISSING ACKs.

ciao walter

[dougie]

...ich hab das gleiche Problem, wollte aber (noch) nichts sagen, weil ich erst genügend Zeit frei schaufen wollte, um eine Fehlersuche unterstützen zu können.

Ich habe den CUL an der FritzBox im rfmode FS20 und einen CUNO im rfmode HomeMatic.
Deine ganzen Arbeiten an der CUL_HM haben bei mir merkliche Verbesserungen gebracht, das ich inzwischen von 10 Versuchen 4 ACKs bekomme. Vorher waren es eher Null.

Ein ping von der Fritzbox zum CUNO sagt mir, das die Laufzeit etwa 4ms beträgt. Zusammen mit der Protokoll-Verarbeitung kommen da vielleicht noch mal ein paar ms dazu.

Ich wollte demnächst umsteigen, und dann den CUL für HM und den CUNO für FS20 nehmen. Aber das löst das o.g. Problem ja nicht.

VG
Ralf

[MisterEltako]

Hallo!

ich weiß zwar nicht, ob euch das in euerem Fall weiterhilft, aber ich hatte immer missing ack's bei gleichzeitigem Schalten mehrerer Aktoren (z.B. um 22:00) sowie disconnected- bzw. reappeared-Zustände bei Verwendung von des HMLAN.
Ich habe dann einen alten Thread bei Google users gefunden, indem das Einfügen von:

select(undef, undef, undef, 0.3);

als letzte Zeile im Abschnitt HMLAN_write($$$) der 00_HMLAN.pm empfohlen wurde.

Seitdem ich das gemacht habe gibt es keine missing ack der Aktoren und kein disconnecten des HmLAN-Adapters mehr. Zudem kann ich nun endlich das Schalten mehrerer Aktoren definieren und diese schalten ohne Fehler.Vielleicht hilft euch ein ähnlicher Eintrag in der Cul/Cuno-Datei.

MfG, MisterEltako.

[wkarl]

Hallo Martin,

lt den logs treten seit dem 04.01. keine MISSING ACKs mehr auf.

Gab es von Deiner Seite Änderungen im HM Modul?

ciao walter

[locodriver]

Bei mir hat das Einfügen der Verzögerung leider auch nichts verändert: Sowohl wenn ich im Gerät als auch im Kanal "Climate" des TC desired-temp ändere kommt ein Missing Ack. Ich konnte jetzt lange nicht "mitmachen", da ich Probleme mit dem CUNO und dessen Verbindung zu HM hatte. Und jetzt habe ich auch noch einen TC zurückschicken müssen, da er sich nicht in den Cent-Modus umschalten ließ. :-( (Meine Freundin hat gesagt:"Endlich", als ich wieder die alten Thermostate an die Heizkörper montiert habe ;-)). Die Ansteuerung der Rollläden funzt aber tadellos.

[martinp876]

kann sein. Ich habe eine Bug eingebaut im duplicate message handling War nur kurz drin - das koennte das Problem gewesen sein.

Sorry...
Martin

p.s. Das Warten von 300ms wäre m.E. tötlich gerade fuer den TC....

[Horst]

kann sein. Ich habe eine Bug eingebaut im duplicate message handling War nur kurz drin - das koennte das Problem gewesen sein.

Interessierte Frage: Wie lange befand sich der Bug in den Sources (könnte auch mein Problem gewesen sein)?

Gruß

Horst