HM-CC-RT-DN Missing ACK

[martinp876]

hi sebixvi,

schau ich einmal durch - aber kannst du hmProtocolEvents abschalten? Das kostet mit unter performance - rate ich davon ab

Gruss Martin

[sebixvi]

Hallo Martin,

ja, werde ich auf jeden Fall versuchen. Ich habe erstmal alles, was mir nach logging klang, eingeschaltet

Inzwischen kann ich mit dem einen Thermostaten "reden" (zumindest ab und zu, ich werde mich noch bemühen, hier eine Regelmäßigkeit herauszufinden). Könnte es sein, dass die noACKs auf ein nicht vollständig erfolgreiches Pairing zurückzuführen sind? Oder antworten die Thermostate auf "Befehle" nicht autorisierter Partner schon gar nicht?

Aufgefallen ist mir, dass nach erfolgtem Pairing (AC im Display und PairedTo=0x424242) ein weiterer Druck auf die Boost-Taste keinen Funkverkehr mehr ausgelöst hat - oder zumindest der HM-CFG-USB hierauf nicht reagiert hat, es liefen keine Meldungen durch.

Ciao,
Sebi

[DosiRocker]

Hallo,
nach meinem Urlaub habe ich vor einem update ein getConfig gestartet (auf allen 4 RTs) und nach kurzer Zeit kam CMDs done.
Danach ein FHEM update gestartet  und ein shutdown restart und dann sofort wieder getConfig und wieder kam nach kurzer Zeit CMDs done.
Also scheint bei mir alles wieder auch mit der offiziellen Version von 00_CUL.pm gut zu sein.

Meine Ausstattung (auf HM Seite):
4*HM-CC-RT-DN (FW 1.0 und 1.1)
Raspberry Pi mit aktueller FHEM
CUL V 1.57 CUL868

Falls du noch Log Infos brauchst bitte melden

Gruß,
Martin

[martinp876]

@Martin,
danke, reicht

@Sebi,
pairing ist entweder ok oder nicht - halb fertig kann es nicht sein. Was halb fertig sein könnte ist die Abfrage der Register nach dem pairing - das sollte automatich passieren.

Aus boost reagiert er nur noch, wenn du etwas länger drückst - aber da sollte schon noch eine Message kommen (config message). Da passieren gelegentlich auch noch aktionen...

Gruss Martin

[libelah]

Hallo zusammen,

Ich glaube ich habe ein ähnliches (das gleiche?) Problem - in jedem Fall kann ich auch zur Datensammlung beitragen
Vielleicht bin ich mit meinem Problem hier auch nicht vollkommen falsch.

habe seit Anfang der Woche einen HM-CFG-USB an meiner FritzBox 7390 hängen (neuestes FHEM von fhem.de, FritzOS 6.01). Dazu 3 HM-CC-RT-DN, mit denen ich für den Anfang gerne 3 Heizkörper steuern will. Nach 3 Abenden/Nächten (*gähn*) habe ich es geschafft die Firmware des USB Sticks und der Thermostate auf die jeweils aktuelleste Firmware zu aktualisieren, den USB-Stick mit FHEM sprechen zu lassen (hmlan-Emulation) und die HM-CC-RT-DN zu pairen - glaube ich wenigstens. "update check" sagte gerade eben auch "nothing to do..."

Bin total neu in der Materie und noch etwas erschlagen - kann gut sein dass ich nicht alle nötigen infos liefere - aber ich werde auf Anfrage nach bestem können nachliefern was nötig ist.

Das Problem: In FHEM sehe ich die aktuelle Temperatur und empfange auch Änderungen die ich am Thermostat mache. Ich kann aber keine Temperaturen in FHEM setzen. Da steht dann (aktuell seit gestern Nacht) "State CMDs_pending" und nichts rührt sich. Hier liest man einiges, dass andere dieses problem mit ähnlichen/gleichen Konstellationen seit kürzerer Zeit ebenfalls haben.
Gibt es vlt einen Stand von FHEM auf den ich zurück kann um zu sehen, dass das ganze prinzipiell funktioniert? Ich brauche mal ein Erfolgserlebnis und würde das auch gerne erleben, solange ich noch mein Rückgaberecht habe.

Zum Pairing: Mir wird die korrekte D-serialNr angezeigt, und bei PairedTo steht 0x424242.
Readings:

Code Auswählen Erweitern

Activity unknown 2014-02-07 20:49:47
CommandAccepted yes 2014-02-07 00:36:33
D-firmware 1.2 2014-02-07 00:26:31
D-serialNr KEQ0729487 2014-02-07 00:26:31
PairedTo 0x424242 2014-02-07 00:26:33
R-backOnTime 10 s 2014-02-07 00:26:33
R-btnLock unlock 2014-02-07 00:26:33
R-burstRx on 2014-02-07 00:26:33
R-cyclicInfoMsg on 2014-02-07 00:26:33
R-cyclicInfoMsgDis 0 2014-02-07 00:26:33
R-globalBtnLock off 2014-02-07 00:26:33
R-localResDis off 2014-02-07 00:26:33
R-lowBatLimitRT 2.1 V 2014-02-07 00:26:33
R-modusBtnLock off 2014-02-07 00:26:33
R-pairCentral 0x424242 2014-02-07 00:26:33
RegL_00: 01:01 02:01 09:01 0A:42 0B:42 0C:42 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00 2014-02-07 00:26:33
RegL_07: 0 2014-02-07 00:39:19
actuator 0 % 2014-02-07 00:38:34
battery ok 2014-02-07 00:38:34
batteryLevel 3.1 V 2014-02-07 00:38:34
desired-temp 17 2014-02-07 00:38:34
measured-temp 22.1 2014-02-07 00:38:34
state CMDs_pending 2014-02-07 20:57:22

Im Event Monitor taucht immer wieder das auf:

Code Auswählen Erweitern

2014-02-07 21:13:23 HMLAN hmusb cond: timeout
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: timeout:1
2014-02-07 21:13:23 HMLAN hmusb prot_timeout: last
2014-02-07 21:13:23 HMLAN hmusb DISCONNECTED
2014-02-07 21:13:23 HMLAN hmusb cond: disconnected
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: disconnected:1
2014-02-07 21:13:23 HMLAN hmusb prot_disconnected: last
2014-02-07 21:13:23 HMLAN hmusb cond: init
2014-02-07 21:13:23 HMLAN hmusb Xmit-Events: init:1
2014-02-07 21:13:23 HMLAN hmusb prot_init: last
2014-02-07 21:13:23 HMLAN hmusb CONNECTED
Ist das normal?

Bei den Logs blicke ich noch überhaupt nicht durch. Da scheint es ja einige zu geben - welche wofür sind, habe ich noch nicht kapiert. 
Hilft davon schon was weiter? Oder ganz anderes Problem? Lieber eigener Thread?

Danke fürs lesen!
Lieben Gruß
Jonas

[uland2012]

Hallo Jonas,

ich kenne das Gefühl ... das wird aber besser

Probier mal folgendes, das hat bei mir definitiv geholfen, seit läuft alles gut:

Habe jetzt in der aktuellen 00_CUL.pm folgenden Eintrag geändert:

# $dDly -= 0.04 if ($mTy eq "02");                                    (Befehl mit# deaktiviert)

Best Grüße und viel Erfolg

Uwe

[libelah]

Hallo Uwe,

Danke für die Antwort!

Ich habe die Zeile per telnet mit vi auskommentiert und fhem mittels "shutdown restart" neugestartet - danach noch die FB komplett. Leider keine Änderung. Es steht immer noch die selbe Anzahl an CMDs pending...

Der Pfad
/var/media/ftp/fhem/FHEM/00_CUL.pm
Zeile #691
sollte stimmen oder? Die Änderung ist dort definitiv vorgenommen.

Gute Nacht 

[martinp876]

Hallo Jonas

du hast HMUSB => 00_CUL interessiert dich nicht. 00_HMLAN ist dein IOdev. Das funktioniert etwas anders.

Die Kommandos für einen RT werden per default beim Aufwachen des RT (alle 2,5min) übertragen. Der RT stellt dann den Wert ein, sendet dann aber noch einmal den alten Wert an FHEM. Erst beim nächsten aufwachen (jetzt also schon 5 min später) - wird FHEM informiert - und der neue Wert ist sichtbar.

Das Übertragen kann man beschleunigen durch Nutzung von Burst. Angezeigt wird der Wert aber auch hier erst beim nächsten Aufwachen nach setzen. Abfragen kann man den Sollwert nicht, man muss warten.

Ist dies dein Problem?

Gruss Martin

[libelah]

Hallo Martin,

Danke für die Antwort!

du hast HMUSB => 00_CUL interessiert dich nicht. 00_HMLAN ist dein IOdev. Das funktioniert etwas anders.

Klingt logisch

Die Kommandos für einen RT werden per default beim Aufwachen des RT (alle 2,5min) übertragen. Der RT stellt dann den Wert ein, sendet dann aber noch einmal den alten Wert an FHEM. Erst beim nächsten aufwachen (jetzt also schon 5 min später) - wird FHEM informiert - und der neue Wert ist sichtbar.

Wenn ich das richtig verstehe sollte also nach ~10min der korrekte Wert wieder in fhem ankommen - bei mir ist er nach 24h noch der alte, bzw. der am RT tatsächlich eingestellte. Denn der RT übernimmt meine Befehle ja gar nicht erst. Insofern denke ich, dass mein Problem ein anderes ist....

Gruß
Jonas
Edit: ich werde es später aber in jedem Fall testen!

Edit2: Jetzt stehen die Devices auf CMDs_done - ohne dass ich nochmal was verändert hätte. Grade noch mal testweise eien Befehl geschickt - der steht aktuell auf MISSING ACK ... ich bin gespannt
Edit3: MISSING ACK hält nun auch schon seit ~20 min an. RT zeigt noch den alten Stand

[martinp876]

Hallo Jonas,

du unterscheidset sicher
- CMDS_done : alles ok, fertig
- CMDS_pending : sind in wartestellung...
- missing ack: device hat nicht wie erwartet geantwortet. Nach einer Anzahl versuche wird das kommando gelöscht

Du kannst einmal loggen, dann kann ich nachsehen...

Gruss Martin

[limats]

Hallo zusammen,

wollte bloß mal kundtun, dass ich auch mit dem heutigen FHEM Stand (09.02.) immer noch das pending-Problem habe.
Wenn ich besagte Zeile aus der 00_CUL.pm auskommentiere, flutscht es aber wie geschmiert.

Gebt Bescheid, wenn ich mit Logs oder Tests unterstützen kann.

Gruß
Leo

[martinp876]

Hallo Leo,

schicke bitte einen roh-log sowie die devices, welche das Problem haben.

Gruss Martin

[limats]

Hallo Martin,

hier das Log, nachdem ich auf getConfig und burstXmit gedrückt hab.

Code Auswählen Erweitern


2014.02.09 21:34:29.480 4: CUL_Parse: CUL A 0C 9E 8670 1FC928 000000 007C3736 -47
2014.02.09 21:34:36.506 4: CUL_Parse: CUL A 0C A9 8670 1FCB96 000000 006A34FF -74.5
2014.02.09 21:34:46.900 4: CUL_send:  CULAs 09 01 B112 F12332 23505A
2014.02.09 21:34:47.416 4: CUL_Parse: CUL A 0A 01 8002 23505A F12332 0023 -56.5
2014.02.09 21:34:47.519 4: CUL_send:  CULAs 10 02 A001 F12332 23505A 00040000000000
2014.02.09 21:34:47.687 4: CUL_Parse: CUL A 1A 02 A010 23505A F12332 020101020109010AF10B230C320E0A0F0023 -56.5
2014.02.09 21:34:47.750 4: CUL_send:  CULAs 0A 02 8002 F12332 23505A 00
2014.02.09 21:34:47.945 4: CUL_Parse: CUL A 18 03 8010 23505A F12332 02110012151600180019001A00000022 -57
2014.02.09 21:34:48.047 4: CUL_send:  CULAs 0B 03 A001 F12332 23505A 0103
2014.02.09 21:34:48.203 4: CUL_Parse: CUL A 0E 03 8010 23505A F12332 010000000023 -56.5
2014.02.09 21:34:48.305 4: CUL_send:  CULAs 10 04 A001 F12332 23505A 01040000000001
2014.02.09 21:34:48.462 4: CUL_Parse: CUL A 0E 04 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:48.564 4: CUL_send:  CULAs 0B 05 A001 F12332 23505A 0203
2014.02.09 21:34:48.720 4: CUL_Parse: CUL A 0E 05 8010 23505A F12332 010000000022 -57
2014.02.09 21:34:48.822 4: CUL_send:  CULAs 10 06 A001 F12332 23505A 02040000000001
2014.02.09 21:34:48.978 4: CUL_Parse: CUL A 0E 06 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.080 4: CUL_send:  CULAs 0B 07 A001 F12332 23505A 0303
2014.02.09 21:34:49.241 4: CUL_Parse: CUL A 12 07 8010 23505A F12332 01247D7A010000000023 -56.5
2014.02.09 21:34:49.344 4: CUL_send:  CULAs 10 08 A001 F12332 23505A 03040000000001
2014.02.09 21:34:49.501 4: CUL_Parse: CUL A 0E 08 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.604 4: CUL_send:  CULAs 10 09 A001 F12332 23505A 04040000000001
2014.02.09 21:34:49.760 4: CUL_Parse: CUL A 0E 09 8010 23505A F12332 020800000023 -56.5
2014.02.09 21:34:49.862 4: CUL_send:  CULAs 10 0A A001 F12332 23505A 00040000000007
2014.02.09 21:34:50.030 4: CUL_Parse: CUL A 1A 0A A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:34:50.092 4: CUL_send:  CULAs 0A 0A 8002 F12332 23505A 00
2014.02.09 21:34:50.289 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204523 -56.5
2014.02.09 21:34:50.351 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:34:50.547 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204523 -56.5
2014.02.09 21:34:50.610 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:34:50.806 4: CUL_Parse: CUL A 1A 0B A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:34:50.868 4: CUL_send:  CULAs 0A 0B 8002 F12332 23505A 00
2014.02.09 21:35:33.327 4: CUL_Parse: CUL A 0F A7 8610 23505A 000000 0AB0E50F5A5823 -56.5
2014.02.09 21:35:33.480 4: CUL_send:  CULAs 09 0B A112 F12332 23505A
2014.02.09 21:36:34.630 4: CUL_Parse: CUL A 0C 9F 8670 1FC928 000000 007C3736 -47
2014.02.09 21:36:51.701 4: CUL_Parse: CUL A 0C AA 8670 1FCB96 000000 006A3500 -74
2014.02.09 21:38:34.637 4: CUL_Parse: CUL A 0C A0 8670 1FC928 000000 007C3736 -47
2014.02.09 21:38:37.082 4: CUL_Parse: CUL A 0F A8 8610 23505A 000000 0AB0E60F5A5823 -56.5
2014.02.09 21:38:37.184 4: CUL_send:  CULAs 09 0C A112 F12332 23505A
2014.02.09 21:38:37.336 4: CUL_Parse: CUL A 0A 0C 8002 23505A F12332 0023 -56.5
2014.02.09 21:38:37.439 4: CUL_send:  CULAs 10 0D A001 F12332 23505A 00040000000007
2014.02.09 21:38:37.606 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:37.669 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:37.865 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:37.928 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:38.124 4: CUL_Parse: CUL A 1A 0D A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:38:38.186 4: CUL_send:  CULAs 0A 0D 8002 F12332 23505A 00
2014.02.09 21:38:56.455 4: CUL_Parse: CUL A 0C AB 8670 1FCB96 000000 006A35FF -74.5
2014.02.09 21:41:24.396 4: CUL_Parse: CUL A 0C A1 8670 1FC928 000000 007C3737 -46.5
2014.02.09 21:41:26.334 4: CUL_Parse: CUL A 0F A9 8610 23505A 000000 0AB0E60F5A5822 -57
2014.02.09 21:41:26.436 4: CUL_send:  CULAs 09 0E A112 F12332 23505A
2014.02.09 21:41:26.588 4: CUL_Parse: CUL A 0A 0E 8002 23505A F12332 0022 -57
2014.02.09 21:41:26.690 4: CUL_send:  CULAs 10 0F A001 F12332 23505A 00040000000007
2014.02.09 21:41:26.859 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050022 -57
2014.02.09 21:41:26.921 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.117 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050023 -56.5
2014.02.09 21:41:27.179 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.377 4: CUL_Parse: CUL A 1A 0F A010 23505A F12332 03012A22093D18030016073000640F050022 -57
2014.02.09 21:41:27.439 4: CUL_send:  CULAs 0A 0F 8002 F12332 23505A 00
2014.02.09 21:41:27.634 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:27.696 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:27.892 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:27.955 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:28.151 4: CUL_Parse: CUL A 1A 10 A010 23505A F12332 03100000090E444855084520452045204522 -57
2014.02.09 21:41:28.213 4: CUL_send:  CULAs 0A 10 8002 F12332 23505A 00
2014.02.09 21:41:50.718 4: CUL_Parse: CUL A 0C AC 8670 1FCB96 000000 006A35FE -75


Und hier der Auszug aus meiner cfg:

Code Auswählen Erweitern


define Bad.Heizung CUL_HM 23505A
attr Bad.Heizung IODev CUL
attr Bad.Heizung actCycle 000:10
attr Bad.Heizung actStatus alive
attr Bad.Heizung autoReadReg 4_reqStatus
attr Bad.Heizung expert 2_full
attr Bad.Heizung firmware 1.0
attr Bad.Heizung model HM-CC-RT-DN
attr Bad.Heizung peerIDs
attr Bad.Heizung room Bad
attr Bad.Heizung serialNr KEQ0574318
attr Bad.Heizung subType thermostat
attr Bad.Heizung webCmd getConfig:clear msgEvents:burstXmit
define FileLog_Bad.Heizung FileLog ./log/Bad.Heizung-%Y.log Bad.Heizung
attr FileLog_Bad.Heizung logtype text
attr FileLog_Bad.Heizung room CUL_HM
define Bad.Heizung_Weather CUL_HM 23505A01
attr Bad.Heizung_Weather model HM-CC-RT-DN
attr Bad.Heizung_Weather peerIDs 00000000,
attr Bad.Heizung_Weather room Bad
define Bad.Heizung_Climate CUL_HM 23505A02
attr Bad.Heizung_Climate model HM-CC-RT-DN
attr Bad.Heizung_Climate peerIDs 00000000,
attr Bad.Heizung_Climate room Bad
define Bad.Heizung_WindowRec CUL_HM 23505A03
attr Bad.Heizung_WindowRec model HM-CC-RT-DN
attr Bad.Heizung_WindowRec peerIDs 00000000,247D7A01,
attr Bad.Heizung_WindowRec room Bad
attr Bad.Heizung_WindowRec stateFormat last:trigLast
define Bad.Heizung_Clima CUL_HM 23505A04
attr Bad.Heizung_Clima model HM-CC-RT-DN
attr Bad.Heizung_Clima peerIDs
attr Bad.Heizung_Clima room Bad
define Bad.Heizung_ClimaTeam CUL_HM 23505A05
attr Bad.Heizung_ClimaTeam model HM-CC-RT-DN
attr Bad.Heizung_ClimaTeam peerIDs
attr Bad.Heizung_ClimaTeam room Bad
define Bad.Heizung_remote CUL_HM 23505A06
attr Bad.Heizung_remote model HM-CC-RT-DN
attr Bad.Heizung_remote peerIDs
attr Bad.Heizung_remote room Bad


Hilft dir das weiter?

Gruß
Leo

[martinp876]

das war jetzt ein log mit burstXmit, also ohne Problem.

kannst du noch einen schicken, wenn kommands pending sind und der RT nicht antwortet? Min 10 min aufzeichenen, damit ein aufwachen dabei ist

Gruss Martin

[limats]

Hallo Martin,

aber trotz burstXmit geht das Device nur kurz auf PROCESSING und bleibt danach ewig in  "CMDs PENDING" stehen. Wenn ich das richtig verstanden habe, müssten doch alle CMDs mit einem burstXmit abgearbeitet werden, oder?
Aber ich schick dir heut abend nochmal einen Log ohne burstXmit.

Gruß
Leo