[gelöst] achtung! ab version 23856 permanente statusrequest bei hm-cc-tc

[frank]

mit der übernahme von noansis vorschlag aus antwort #24 in die aktuelle 10_CUL_HM.pm sind die permanenten statusrequest nach fhem restart nun verschwunden, danke.

[Jamo]

Hi Frank,
mit der übernahme von noansis vorschlag aus Antwort #24 in die aktuelle 10_CUL_HM.pm (Update heute) sind die permanenten getconfig aus Antwort #28 nun auch verschwunden.
Deswegen jetzt kein neuer Thread.

Danke!

[frank]

ich haben den log durchgesehen. Die Kommandos kommen erst einmal -unabhängig von noansi's Anmerkungen.
Die Requests werden gesendet wie erwartet und manchmal beantwortet. Also ist ein ein Ablauftechnisches sondern ein Timing Problem.

-EE 8670 20DFE1 000000 00BB2E wird 2-mal gemeldet - einmal von jedem IO. OK so weit aber mit 250ms Abstand. Offensichtlich ist etwas in dem System "unangemessen langsam"! 10ms sind ok. 250ms eine Kathastrophe!

- Typisch werden die Meldungen in einem ordentlichen Abstand erfasst (10-30ms).
- Beim Erfolgreichen Versuch wird die Anfrage nach mehr als 100ms gesendet - wie erwartet.

#> HMLAN meldet ein ack mit msgNummer "12" während  das LGW eine "F2 meldet. HMLAN macht desen Dreher häufiger, wie zu sehen ist - es sieht so aus, als ob manchmal die oberen 3 Bit gekappt werden.
#>HMLAN und LGW melden ein Ack 250ms später noch einmal - diesmal beiden mit korrekter Sequenz. Das Timing deuted auf eine Wiederhlung hin.


M.E. hat dieses Alte Model (model, das detailierte Device) grundsätzliche Protokoll-Probleme. Ich stelle in den Raum, dass eq3 bei neuerer FW (anderer Modelle) robustere FW nutzt.

Fakten:
- die Message Sequenz ist ok - was der erfolgreiche Ablauf beweist
- Das TC vertut sich in der Messagenummer oder der ganzen mesage. Ein LGW ignorert die messages (hier ein ack) während ein HMLAN es durchwinckt.
- wahrschienlich ist das erste delay (250ms) nicht FHEM geschuldet sondern der Protokol-inkompetentz des TC. Erst beim 2. Versuch wird eine gültige message gesendet!

Wie kann man damit umgehen. Es scheint ausschliesslich ein Problem der alten Modelle zu sein und nur bei wakeup relevant. Ein sehr eingeschränktes Problem also.
Die FW umzu stellen ist nicht clever, da es eine Gefahr für 90% der Devices wäre   und somit nicht zu rechtfertigen ist.

Wahrscheinlich könnte es durch drehen am Timing korrigiert werden. Eswas schneller oder langsamer...

das problem, das du beschreibst, liegt an den A112 messages, die sowohl autonom vom io (hmuart) gesendet werden, als auch explizit über fhem. daher die unterschiedlichen msg nummern.

das problem ist in der aktuellen 10_cul_hm.pm nun nicht mehr vorhanden.

zur zeit macht set statusrequest probleme, siehe https://forum.fhem.de/index.php/topic,119853.msg1146212.html#msg1146212

[no_Legend]

Ich hab einen Hm Regensensor.
Das Log läuft mega voll, mit Meldungen wie in Post 1.

Es scheint aber nur der Regen Sensor im log mit cul-hm stehen.
Zumindest wie ich es schnell prüfen konnte.

Grüße Robert

[frank]

dann mal die rawmessages sniffen.

[no_Legend]

dann mal die rawmessages sniffen.

Nix für ungut.
Aber bis zum letzten Update ohne Problem gelaufen.
Hab gerade aber festgestellt das noch viel mehr Geräte gerade keine Lust mehr haben.
Der 24v Dimmer versagt auch seinen Dienst. Missing ACK
Der Dimmer an sich geht aber, ist noch mit einem anderen Taster gepeert.
Ein 230v Dimmer hingegen geht ohne Problem.

Alles homematic Geräte