Viele Probleme mit HM-TC-IT-WM-W-EU

[billiloumez]

Hallo zusammen,

ich bin neu hier im Forum und relativ neu im FHEM Thema, habe mich aber durch die sehr gute Dokumentation und das Forum schon relativ gut durchgekämpft bis jetzt, dafür schon mal vielen Dank!

Ich betreibe unter anderem in allen meinen Zimmern HM Wandthermostate (HM-TC-IT-WM-W-EU), Stellantriebe (HM-CC-RT-DN) und Fensterkontakte (HM-SEC-SC-2).
Was sehr gut funktioniert hat war das pairing mit FHEM über den CUL, sowie das peering untereinander, hier reagiert alles sofort, wenn z.B. Fenster geöffnet werden, oder man Temperaturen manuell einstellt.
Was leider sehr sehr unzuverlässig funktioniert ist die Automatisierung über FHEM über CUL, z.B. in Hinblick auf Anwesenheitserkennung. Was passiert ist, dass der CUL Befehle sendet, die Wandthermostate aber manchmal nur extrem langsam, manchmal überhaupt nicht Befehle verarbeiten, bis ich selber manuell x-mal getConfig absetze. Sie stehen ansonsten ewig in z.B. den Stati "RESPONSE TIMEOUT:RegisterRead" oder "CMDs_pending".

Ich habe dazu mal ein paar Screenshots angehängt, in der Hoffnung, dass ihr da mehr rauslesen könnt wie ich. Das Problem betrifft eigentlich alle meine Wandthermostate, mal funktioniert es auch, oft aber nicht.

Im Wesentlichen sind es drei Sachen, die ich Momentan über FHEM versuche abzubilden.

1. Zeitabgleich der HM Devices:

Code Auswählen Erweitern


define at_HMZeitabgleich at *05:05 set HM_43F8F7,HM_43F8E2,HM_34D135,HM_34D08D,HM_4418B5,HM_43F8EE,HM_34D2D9,HM_460695 sysTime;;sleep 60;;set HM_43F8F7,HM_43F8E2,HM_34D135,HM_34D08D,HM_4418B5,HM_43F8EE,HM_34D2D9,HM_460695 getConfig


2. Aktion bei Abwesenheit:

Code Auswählen Erweitern


define n_HeizungAbwesend notify Anwesenheit.0 set HM_34D2D9_Climate,HM_460695_Climate,HM_34D135_Climate,HM_34D08D_Climate controlMode manual;;sleep 60;;set HM_34D2D9_Climate,HM_460695_Climate,HM_34D135_Climate,HM_34D08D_Climate desired-temp 17.0;;sleep 60;;set HM_43F8F7,HM_43F8E2,HM_34D135,HM_34D08D,HM_4418B5,HM_43F8EE,HM_34D2D9,HM_460695 getConfig


3. Aktion bei Anwesenheit:

Code Auswählen Erweitern


define n_HeizungAnwesend notify Anwesenheit.1 set HM_34D2D9_Climate,HM_460695_Climate,HM_34D135_Climate,HM_34D08D_Climate controlMode auto;;sleep 60;;set HM_43F8F7,HM_43F8E2,HM_34D135,HM_34D08D,HM_4418B5,HM_43F8EE,HM_34D2D9,HM_460695 getConfig


Die Auslösung der Aktionen durch FHEM funktioniert auch ausgezeichnet, aber eben nicht die Umsetzung durch die HM Devices.

Ich bin wie gesagt noch relativ neu in dem Thema, also verzeiht mir bitte etwaige Unzulänglichkeiten und lasst mich wissen, was noch für notwendige Informationen benötigt werden.

Vielen Dank schon mal im Voraus!

[franky08]

Hallo, wenn ich mir den screenshot ansehe, fällt mir auf das dein fhem nicht aktuell sein kann! Das Attribut expert gibt es so, wie bei dir schon eine Weile nicht mehr. Mach mal unbedingt ein update.

P.S. besser ist ein list <device> zu posten, ist besser lesbar als ein Screenshot

VG
Frank

[billiloumez]

Das letzte Update habe ich zwecks DUOFERN Einbindung erst vor ca. 2 Wochen gemacht, ich habe trotzdem gerade noch eins gemacht. Evtl. ist das Attribut bei mir noch ein "Relikt" von der vormals alten Version?

[frank]

ich denke, dass du dein system ziehmlich quälst.
bei jedem getconfig auf ein device werden auch die daten aller channel angefordert. da kommt bei tc-it allerhand zusammen. wozu überhaupt die getconfig? es werden doch keine register verändert. die getconfig würde ich alle entfernen. die zeitsyncronisierung sollte auch überflüssig sein, da sie automatisch einmal am tag durchgeführt wird.
da du deine befehle nicht als burst absetzt, ist auch gut so, kann die kommunikation bis zu 3 min verzögert sein. da nützt das "sleep 60" dann auch nichts, zumal sämtliche konfigdaten sicherlich auch nicht während einer kommunikationsphase abgearbeitet werden können.
wenn nach der reduzierung immer noch befehle "verloren" gehen, könntest du das attr msgrepeat eventuell erhöhen.

[Otto123]

Mit welcher Firmware betreibst Du den CUL?

Das Timing vom CUL ist für Homematic nicht optimal. Ich lese das immer wieder hier im Forum. So ein Gerät wie der Thermostat schickt viele Daten, wie frank schon sagt, ein ständiges getConfig ist Gift für die Datenübertragung.

Viele sagen immer wieder: CUL kann gut gehen muss aber nicht...

Gruß Otto

[billiloumez]

Die getConfigs habe ich erst gestern eingebaut, weil ich mir davon versprochen habe, dass es evtl. zuverlässiger läuft, tut es aber nicht. Ich hatte vorher mit den gleichen Befehlen, ohne getConfig und ohne sleeps schon genau die gleichen Probleme, wir reden hier auch nicht von 3 Minuten, bis sich was tut, sondern die stehen den ganzen Tag auf CMDs_pending wenn ich nicht irgendwann händisch eingreife, nämlich mit getConfig. Erst dann gibt es irgendwann wieder ein CMDs_done. Das ist dann leider für automatische An- und Abwesenheitserkennung ziemlich untragbar.

Das mit den msgrepeat werd ich mal ausprobieren!

Ich habe den CUL mit der letzten "Standard" Firmware geflasht, diese angepasste für HM Timings habe ich gerade erst entdeckt. Gibts da irgendwas zu beachten? Muss ich irgendwas sichern was beim flashen verloren geht?

[schroediman]

Hi  billiloumez,

ich habe mich auch mit 8 HM-TC-IT-WM-W-EU und "getconfig" und einem COC (CUL für Raspi) lange gequält. Mit wenigen Thermostaten und wenigen anderen HM-Devices lief es noch gut ; aber mit dem Vollsystem war an ein "getconfig" beim HM-TC-IT-WM-W-EU gerade wegen der langen Temperaturlisten nicht zu denken.

Vielleicht hat sich hier die Firmware des CUL inzwischen etwas verbessert. Ich bin dann irgendwann aus anderen Gründen auf 'nen HM-USB-Config2-Adapter umgestiegen und das einzige Problem was ich hatte war nur noch das, dass der irgendwann (viel zu früh) mit der 1%-Regel gewunken hat und in Overload ging.

Kann mich hier nur anschließen:

Viele sagen immer wieder: CUL kann gut gehen muss aber nicht...

MfG

Sebastian