HM-CC-RT-DN nimmt keine Kommandos an / hmid löschen

[frank]

´Wie kann ich erkennen das der Thermostat wach ist? -> "solange der countdown läuft, ist der rt wach". Daraus resultiert die Wartezeit bis ich 2b auslösen kann.

nein!!!
wenn der countdown läuft, hast du doch schon gedrückt. 

was ist daran so schwierig?
DU MUSST NICHTS ERKENNEN!
du musst nur die reihenfolge einhalten: erst 1. danach dann 2.b)
möglichst umgehend.

1. Kann ich auf den CUL die tsculfw flashen?
2. Wo kann ich die Firmware downloaden?
3. Wo finde ich ein HowTo für die beschriebene Lösung

https://forum.fhem.de/index.php?msg=1320574

4. Welchen IO von EQ3 meinst?

alle

5. Gibt es Einstellungen bei dem CUL damit ich die communication verbesserb kann?

nein

#######################

zu 1. - wenn ich einen "set NN_AZ1_HZ1 getConfig" wecke ich den Thermostat, welche Latenzen habe ich dann?

           - Also eingabe in Oberfläche, übertragen der Anforderung an den Thermostaten
           - aufwecken des Thermostaten
           - wie lange bleibt der Thermostat wach

keine ahnung was du meinst.
die devices sind immer dann wach, wenn sie etwas senden. vielleicht 200ms?


in deinem log war zb auch ein automatischer versuch eines anderen devices zu sehen:

Code Auswählen Erweitern

2024.11.13 15:44:23.453 4: CUL_Parse: CUL_868 A 0D 16 8610 68DD83 000000 0601000037 -46.5
2024.11.13 15:44:23.472 5: CUL_868: dispatch A0D16861068DD8300000006010000::-46.5:CUL_868
2024.11.13 15:44:23.707 3: CUL_HM set NN_FL1_TK1 getConfig noArg
2024.11.13 15:44:23.724 5: CUL_868 sending As0917A11262626268DD83
2024.11.13 15:44:23.728 5: DevIo_SimpleWrite CUL_868: As0917A11262626268DD83
275msdas antworten dauert nach log timestamps von fhem eingang bis fhem ausgang 275ms.
da fehlen ja dann noch die zeiten vom device über den cul zu fhem und zurück von fhem über den cul zum device.


bei mir sieht ein vergleichbarer vorgang so aus:

Code Auswählen Erweitern

2024.11.03 16:35:40.970 4: CUL_Parse: cul868 A 0C E0 8670 1DFDA5 000000 00764BFA -77
2024.11.03 16:35:40.973 5: cul868: dispatch A0CE086701DFDA500000000764B::-77:cul868
2024.11.03 16:35:41.015 5: cul868 sending As09E1A1121ACE1F1DFDA5
2024.11.03 16:35:41.018 5: CUL 1DFDA5 dly:54ms
2024.11.03 16:35:41.076 5: DevIo_SimpleWrite cul868: As09E1A1121ACE1F1DFDA5
106ms (davon 54ms warten!!!)das sind nur 106ms und noch wichtiger: davon wartet fhem sogar über die hälfte der zeit, damit die message nicht zu früh ankommt! also dauert bei mir die verarbeitung nur 52ms.
da bei dir keine wartezeit zu sehen ist, hat fhem wohl viel zu tun.

dann habe ich noch einen alten hmlan, der die beiden messages gehört hat:

Code Auswählen Erweitern

2024.11.03 16:35:41.137 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:581D502E d:FF r:FFCC     m:E0 8670 1DFDA5 000000 00764B
2024.11.03 16:35:41.141 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:581D50B4 d:FF r:FFE4     m:E1 A112 1ACE1F 1DFDA5          +134
hmlan sagt 134msder hmlan macht eigene timestamps, die hier sagen, dass 134ms abstand zwischen den messages waren. das ist sozusagen die gesamte antwort dauer.
bei mir muss ich also etwa 30ms zu den fhem cul-logzeiten dazu zählen.


der entscheidende unterschied ist aber, dass dein device nicht antwortet.
daher ist die vermutung, dass es bereits wieder eingeschlafen ist, bevor die antwort kam.

bei mir ging es dann so weiter:

Code Auswählen Erweitern

2024.11.03 16:35:41.238 4: CUL_Parse: cul868 A 0A E1 8002 1DFDA5 1ACE1F 00FA -77
2024.11.03 16:35:41.243 5: cul868: dispatch A0AE180021DFDA51ACE1F00::-77:cul868
2024.11.03 16:35:41.291 5: cul868 sending As0BE2A0011ACE1F1DFDA5020E
2024.11.03 16:35:41.294 5: CUL 1DFDA5 dly:48ms
2024.11.03 16:35:41.346 5: DevIo_SimpleWrite cul868: As0BE2A0011ACE1F1DFDA5020E
2024.11.03 16:35:41.409 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:581D5139 d:FF r:FFCC     m:E1 8002 1DFDA5 1ACE1F 00       +133
2024.11.03 16:35:41.414 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:581D51C5 d:FF r:FFE3     m:E2 A001 1ACE1F 1DFDA5 020E     +140

ich habe einen pi3 der ersten generation und einen vielleicht 8 jahre alten cul von busware.
meine eigene culfw(V2.67) ist vielleicht gerade extrem schnell, aber das würde dir auch nicht helfen.

die tsculfw sollte schon deutliche verbesserungen bringen, aber die latenzen deines fhem kann sie auch nicht eleminieren. da solltest du mal mit apptime und/oder freezemon debuggen.
die latenzen von hminfo waren ja schon gruselig.


gruss frank

[frank]

als workaround könntest du erstmal bei allen rt burst benutzen.
das hat ja scheinbar funktioniert (du hast ja leider nichts dazu gesagt).
das konfigurieren könnte auf die manuelle weise mühselig werden.   

aber nicht darauf ausruhen, denn das könnte auch weitere probleme verursachen.

[mikawood]

Hi Frank

ich habe mir den Wiki Eintrag https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat angeschaut.

So aktiviert man den burst-Betrieb am HM-CC-RT-DN

Burst Mode einschalten (der Kanal 4 des Device WZ1 heisst hier WZ1_4)

set WZ1_4 regSet burstRx on
prüfen mit:

get WZ1_4 reg burstRx
Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)

attr WZ1 burstAccess 1_auto

Bei mir ist der Ch04 als NN_AZ1_HZ1_Clima gesetzt.

Darauf hin habe ich folgendes versucht

Burstmodus setzten
     set NN_AZ1_HZ1_Clima regSet burstRx on

Kontrolle ob das Register gesetzt ist
     get NN_AZ1_HZ1_Clima reg burstRx
Ist leider nicht gesetzt

Versuch das Register setzen ->
     set NN_AZ1_HZ1_Clima burstXmit

gewartet! Leider nichts

Was mache ich falsch?

Mfg
Micha

[frank]

wenn du deine channel selber inspiziert hättest, hättest du auch gesehen, dass das register burstRx nicht in channel 4 zu finden ist, sondern im hauptdevice. 

also steht da mist im wiki.

[mikawood]

Hallo Frank

ich habe jetzt mal auf allen Thermostaten das Attribute burstAccess auf 1_auto gesetzt (attr NN_AZ1_HZ1 burstAccess 1_auto) nicht wie im wiki Beschrieben ist das Register.
Aktuell kann ich jetzt wieder auf allen RT die Temperaturen wieder FTUI und meine Funktion wieder setzen. Danke für den Hinweis. Bin Momentan sehr mit Altbaurenovierung beschäftigt. Ich versuche am Wochenende mal die Anweisungen von dir Umzusetzen, ich gebe dir dann wieder neue Stati.

mfg
Micha