HM-CC-RT-DN Missing ACK

[DosiRocker]

Hallo Martin, Hallo RosiDocker,

ich habe mal die Zeile

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.08) if ($mTy eq "02");

in die 00_CUL.pm eingebaut und getestet ...... aber auch bei

$dDly -= 0.1 + AttrVal($hash->{NAME},"ackDly",0.03) if ($mTy eq "02");

gibt es immer noch Probleme !

Wie genau interpretiert man das Ganze ?

@ Rosidocker wie sieht das bei Dir aus ?

Gruß
Klaus

Hallo Klaus,
ich hoffe du meintest mich (RosiDocker -> DosiRocker)

Ich habe mich strikt nach Martins Anweisung aus Antwort 23 in diesem Thread gehalten und dann die Zeile

Code Auswählen Erweitern

$dDly -= 0.08 if ($mTy eq "02");.
die 0.08 durch 0.04 ersetzt.
Dies läuft bei mir seit dem so.

oder du wartest bis die Änderungen in der 00_CUL.PM eingecheckt wurden, dies sollte nach Aussage von Martin demnächst passieren.

Gruß,
Martin

[martinp876]

Hi,

Rudi hat es eingecheckt - heute => entweder heute aus SVN oder morgen im Update

danach verfolgen wir wieder, was übrig ist

Gruss Martin

[kvo1]

@DosiRocker
>>>ich hoffe du meintest mich (RosiDocker -> DosiRocker)
ja sooooorrrry , der typische Buchstabendreher ?

@Martin
Danke , dann warte ich mal mit  weiteren Tests.!

klaus

[sebixvi]

Moin,

ich glaube, der RT hat ein grundsätzliches Problem mit Burst-Übertragungen. Ich habe gestern anhand einer kursierenden Anleitung einen RaspPi in eine CCU2 verwandelt und als Zentrale zusammen mit einem HM-CFG-USB (per hmland) verwendet.

Ergebnis: auch damit funktioniet das Pairing erst nach mehreren Versuchen, egal, ob der RT im selben Raum oder etwa 4m entfernt ist (RSSI jeweils <=70). Und auch im CCU2 hält sich besändig die Meldung "Gerkätekommunkation gesört" sowie "Konfigurationsdaten stehen zur Übertragung an". Eine Temperaturliste konnte ich mit der CCU2 nur übertragen, wenn ich am schon gepairten RT durch Aktivierung des Pairing-Modus die Übertragung angestoßen habe. Nach einigen Versuchen war die Liste dann endlich übertragen. Die Übertragung von der CCU2 an den RT wird dagegen immer mit einer Fehlermeldung ("Übertragung konnte nicht erfolgreich abgeschlossen werden") quittiert.

Die Logs des fhem zeigen keine Fehlermeldungen, solange man keinen Burst-Modus benutzt. Sobald aber " Burst=1" gesetzt ist, kommen die Messages nicht mehr durch bzw. werden vom RT (jedenfalls von meinem) nicht richtig verstanden.

Ich bekomme heute noch ein bißchen "Spielkram" (u.a. weitere RTs und einen 1-Kanal-Empfänger), wenn ich die habe, werde ich mal weiter testen.

Hat jemand eine Konfig, in der ein RT wirklich ohne Fehlermeldungen funktioniert? CCU1, CCU2, CUL oder was auch immer?

Sebi

[martinp876]

Hi Sebi,

kannst du einmal mitloggen, wenn du den RT anlernst - incl roh-messages?

was meinst du mit Konfig, in der der RT funktioniert? Hast du ein Problem mit Anlernen oder mit Betrieb?
Im Übrigen - beachte die Änderung im 00_CUL von heute (morgen im update, heute in SVN)

Gruss Martin

[sebixvi]

Hallo Martin,

ja, ich werde - spätestens am Wochenende - mal ausführlich loggen und vor allem mal mit anderen Geräten testen.

Mit Konfig, die funktioniert, meine ich einen Aufbau, bei dem es nicht ständig Fehlermeldungen hagelt. Bisher habe ich getestet:

- HM-CFG-USB direkt am PC bzw. per hmland als HM-CFG-LAN mit der Homematic-Software unter Windows
-> Anlernen funktioniert prompt, Auslesen funktioniert auch, ebenso Übertragen der Sollwerte. Übertragen des Temperaturprofils klappt nur mühsahm, die Software zeigt immer eine Fehlermeldung an, in den Statusmeldungen sehe ich "Gerätekommunkation ist gestört" bzw. "Gerätekommunikation war gestört" sowie "Es stehen Konfigurationsdaten zur Übertragung an". Diese Meldungen bekomme ich nicht weg, egal, was ich anstelle.

- RaspPi als CCU2 konfiguriert mit HM-CFG-USB per hmland als Netzwerk-Device
-> wie oben. Es funktioniert "ein bißchen", aber ständig werden Fehlermeldungen ausgegeben. Temperaturprofil z.B. wird nur beim Aktivieren des Pairing-Mode einmalig übertragen, sonst nicht.

- fhem und HM-CFG-USB per hmland
-> Anlernen funktioniert nach 5-6 Versuchen, Werte vom RT werden übernommen, Temperaturlisten schreiben geht gar nicht, ständig CMDs pending

Dabei macht es keinen Unterschied, wie weit der RT vom Sender entfernt ist, die RSSI-Daten sprechen für mich dafür, dass die Funkstrecke in Ordnung ist. Auch der Umstand, dass ich ein Firmware-Update per OTA überspielen konnte, heißt für mich, dass die reine Übertragung nicht allzu fehleranfällig ist.

Bei fhem alleine könnte es sein, dass etwaige Protokoll-Spezialitäten nicht sauber umgesetzt sind. Aber genau das dürfte beim Einsatz "originaler" HM-Komponenten eben nicht auftreten. Also entweder ist eins (oder mehrere) meiner Geräte defekt, oder der RT hat ein grundsätzliches Problem. Und deshalb die Frage, ob irgendwer den RT völlig problemlos und ohne Fehlermeldungen mit welcher Hard- und Software einsetzt.

Ciao,
Sebi

[martinp876]

hi sebi,

ah HW config...

direkt am PC ... unter Windows

kann ich keine Aussage machen. Zum Kommunikation brauchst du präzises Timing - ob windows da geeignet ist habe ich nie getestet. Ich nutze in wesentlichen eine FB

RaspPi als CCU2 konfiguriert mit HM-CFG-USB

sollte von der Performance her reichen.

Bin auf die Logs gespannt - insbesondere da es HM-IOs sind, die liefern zusätzliches Timing.
Sende dann auch die Auswertung den HMUSB - also die Delays.
Evtl auch einmal apptime ansehen... falls es jemand anders (task oder prozess) ist
Gruss Martin

[Herr 3x]

Bei fhem alleine könnte es sein, dass etwaige Protokoll-Spezialitäten nicht sauber umgesetzt sind. Aber genau das dürfte beim Einsatz "originaler" HM-Komponenten eben nicht auftreten. Also entweder ist eins (oder mehrere) meiner Geräte defekt, oder der RT hat ein grundsätzliches Problem. Und deshalb die Frage, ob irgendwer den RT völlig problemlos und ohne Fehlermeldungen mit welcher Hard- und Software einsetzt.

Bis vor kurzem lief hier alles recht problemlos mit HMLAN und 7390. Anlernen von den RT war kein Problem.
Jetzt mit HMLAN und OS X bekomme ich keine Temperaturen mehr gesetzt. Bei keinem von 9 RT.
Beim HMLAN habe ich mal ein Softwareupdate gemacht, ohne erfolg.
Ich probiere am Wochenende nochmal den Weg zurück auf die FB. Wenn es dann geht liegt es am Server.

Herr 3x

[kvo1]

Hallo Martin,
ich habe die 00_CUL.pm per fhem-Update eingespielt und grob getestet.
Bisher habe ich mit meinen 5 RT´s keine Probleme, werde das aber weiter
beobachten !

Danke & Gruß
Klaus

[uland2012]

Hallo,

ich kämpfe auch mit dem Fehler des dauernden pending und processing.

Habe jetzt in der aktuellen 00_CUL.pm (Upfate von heute) folgenden Eintrag geändert:

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

Diese Zeile war in der Version der 00_CUL.pm vom 29.01.14 (meine Backup vom Update)
nicht vorhanden.

Jetzt habe ich zumindest kein dauerndes pending und processing mehr

Ob diese Änderung von Dauer ist muss ich erst abwarten.
Heute Abend kann ich dann sehen ob das Antennen Symbol an den HM-CC-RT-DN wieder den normalen Zustand erreicht.

[dman]

...vielleicht etwas anachronistisch (da ja schon neue Version da), aber hier noch die Bestätigung , dass mit der Version von Post #29 und der Einstellung für ackDly = 0.05 meine Missing ACK-Probleme bei den Schaltaktoren/-dimmer HM-LC-Sw1PBU-FM und HM-LC-Dim1TPBU-FM offenbar beseitigt sind. Jedenfalls habe ich seit über 2 Tagen keine mehr (normalerweise waren spätestens nach 1 Tag welche da).

[CUL an Raspberry PI]

[martinp876]

Hallo Leute,

die Zeile
# $dDly -= 0.04 if ($mTy eq "02");
ist ein Problem, war zu befürchten.
Kurzer Hintergrund: wir haben Fälle, da ein ACK softrt gesendet werden muss - und Fälle, in denen das ACK nicht vor 60ms nach der message gesendet werden muss.
Da ich keine Unterlagen habe, wann genau welche Verzögerung notwendig ist müssen wir die Daten sammeln. In einer alten Version hatten wir einen 100ms delay - nach ein paar Problemen und erfolgreichem test ist der auf 0 gesetzt worden, was dann bei anderen zu Problemen führte. Ausgemessen wurde, dass ein Delay von 60ms reichte....

Jetzt also eine Datenerhebung. Bitte posten, wer Probleme hatte.
- mit welcher Version ging es, mit welcher nicht?
- Welches Device?
- mit HMLAN/USB oder CUL (hier eigentlich nur CUL/CUNO,...)
- virtueller Peer oder Aktion mit FHEM/Zentrale
- ggf logs

Ich werden versuchen zu ergründen, wann welcher delay angesagt ist

Gruss Martin

[sebixvi]

Hallo,

hier ein paar Logs. Ich habe einen neuen Thermostat angelernt, das hat ca. 10 Versuche benötigt (5 bis zum "AC", dann nochmal etwa 5 bis set_ bei R_pairCentral verschwunden war und ich readings hatte).

Der ebenfalls inzwischen angelernte HM-LC-Sw1-BA_PCB funktioniert übrigens einwandfrei. Zwar gibt es hier kurzzeitig mal "Missing ACK", aber das verschwindet innerhalb von 1-2s gleich wieder. Schalten tut er problemlos, das Anlernen hat auch auf Anhieb geklappt.

list hm-cc-rt-dn:



Internals:
   CFGFN     
   DEF        22E536
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     26
   NAME       thermostat_wz
   NR         185
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_22E536_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_22E536_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_22E536_WindowRec
   channel_04 CUL_HM_HM_CC_RT_DN_22E536_Clima
   channel_05 CUL_HM_HM_CC_RT_DN_22E536_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_22E536_remote
   hmusb_MSGCNT 26
   hmusb_RAWMSG E22E536,0000,0066F0F9,FF,FFE1,1E861022E5360000000A88E4100018
   hmusb_RSSI -31
   hmusb_TIME 2014-02-06 00:24:43
   lastMsg    No:1E - t:10 s:22E536 d:000000 0A88E4100018
   protCmdPend 6 CMDs pending
   protLastRcv 2014-02-06 00:24:42
   protResnd  8 last_at:2014-02-06 00:24:44
   protSnd    25 last_at:2014-02-06 00:24:43
   protState  CMDs_pending
   rssi_at_hmusb avg:-37.34 min:-45 max:-30 lst:-31 cnt:26
   Readings:
     2014-02-05 23:56:48   Activity        alive
     2014-02-06 00:14:10   CommandAccepted yes
     2014-02-05 23:56:49   PairedTo        0x424242
     2014-02-05 23:56:49   R-backOnTime    10 s
     2014-02-05 23:56:49   R-btnLock       unlock
     2014-02-05 23:56:49   R-burstRx       off
     2014-02-05 23:56:49   R-cyclicInfoMsg on
     2014-02-05 23:56:49   R-cyclicInfoMsgDis 0
     2014-02-05 23:56:49   R-globalBtnLock off
     2014-02-05 23:56:49   R-localResDis   off
     2014-02-05 23:56:49   R-lowBatLimitRT 2.1 V
     2014-02-05 23:56:49   R-modusBtnLock  off
     2014-02-05 23:56:49   R-pairCentral   0x424242
     2014-02-05 23:56:49   RegL_00:          01:00 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-06 00:14:41   RegL_07:       
     2014-02-06 00:24:43   actuator        0 %
     2014-02-06 00:24:43   battery         ok
     2014-02-06 00:24:43   batteryLevel    3.1 V
     2014-02-06 00:24:43   desired-temp    17
     2014-02-06 00:24:43   measured-temp   22.8
     2014-02-06 00:24:44   state           CMDs_pending
   cmdStack:
     ++A00142424222E53600040000000007
     ++A00142424222E5360503
     ++A00142424222E53605040000000001
     ++A00142424222E5360603
     ++A00142424222E53606040000000001
     ++A01142424222E536860414
   Helper:
     cSnd       0142424222E53600040000000007
     mId        0095
     rxType     140
     Io:
       nextSend   1391642683.03501
     Prt:
       bErr       0
       sProc      2
       wuReSent   3
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmusb:
         avg        -37.3461538461539
         cnt        26
         lst        -31
         max        -30
         min        -45
     Shregw:
       07         04
     Shadowreg:
Attributes:
   IODev      hmusb
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.1
   model      HM-CC-RT-DN
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0733977
   subType    thermostat
   webCmd     :burstXmit

list hmusb:

Internals:
   DEF        192.168.0.20:1000
   DeviceName 192.168.0.20:1000
   FD         10
   HM_CMDNR   35
   NAME       hmusb
   NR         20
   NTFY_ORDER 50-hmusb
   PARTIAL   
   RAWMSG     E22E536,0000,00690D0A,FF,FFE1,1F861022E5360000000A88E4100018
   RSSI       -31
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDs 22BBF5,2392DE,22E536
   assignedIDsCnt 3
   assignedIDsReport 3
   firmware   0.967
   hmusb_MSGCNT 53
   hmusb_TIME 2014-02-06 00:27:01
   msgKeepAlive dlyMax:0.03 bufferMin:4
   msgLoadEst 1hour:2% 10min steps: 0/0/0/2/0/0
   owner      424242
   serialNr   IEQ0435240
   uptime     000 01:54:48.779
   Readings:
     2014-02-05 23:06:40   Xmit-Events     ok:1
     2014-02-05 23:06:40   cond            ok
     2014-02-04 00:26:14   prot_ERROR-Overload last
     2014-02-03 02:10:52   prot_Warning-HighLoad last
     2014-02-05 23:06:37   prot_disconnected last
     2014-02-05 23:06:37   prot_init       last
     2014-02-05 22:12:00   prot_keepAlive  last
     2014-02-05 23:06:40   prot_ok         last
     2014-02-02 11:53:18   prot_timeout    last
   Assids:
     22BBF5     1
     22E536     1
     2392DE     1
   Helper:
     assId      0
     000001:
       flg        0
     22bbf5:
       chn        00
       flg        0
       msg       
       name       thermostat_az
       newChn     +22BBF5,00,01,
       to         1391641157.7493
     22e536:
       chn        00
       flg        0
       msg       
       name       CUL_HM_HM_CC_RT_DN_22E536
       newChn     +22E536,00,01,
       to         1391642823.20761
     2392de:
       chn        02
       flg        0
       msg       
       name       CUL_HM_HM_LC_SW1_BA_PCB_2392DE
       newChn     +2392DE,00,01,
       to         1391639093.15944
     424242:
       flg        0
     Assids:
     K:
       BufMin     4
       DlyMax     0.03
       Next       1391642850.30569
       Start      1391642825.30569
     Log:
       all        1
       sys        1
       ids:
         all
         sys
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       apIDs:
       Cap:
         0          0
         1          7
         2          6
         3          0
         4          0
         5          35
         last       2
         sum        48
     Ref:
       hmtL       6888779
       kTs        0
Attributes:
   addvaltrigger 1
   hmId       424242
   hmLanQlen  1_min
   hmProtocolEvents 1_dump
   logIDs     sys,all
   verbose    5
   wdTimer    25

list global:

Internals:
   DEF        <no definition>
   LASTInputDev hmusb
   MSGCNT     4
   NAME       global
   NR         1
   STATE      <no definition>
   TYPE       Global
   currentlogfile ./log/fhem-2014-02.log
   hmusb_MSGCNT 4
   hmusb_RAWMSG R04403F43,0001,00490995,FF,FFD6,13A01022E536424242020100020109010A420B420C420E0A0F00
   hmusb_RSSI -42
   hmusb_TIME 2014-02-05 23:52:03
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   logfile    ./log/fhem-%Y-%m.log
   modpath    .
   motd       SecurityCheck:

WEB,WEBphone,WEBtablet has no basicAuth attribute.
telnetPort has no password/globalpassword attribute.
Running with root privileges.
Restart fhem for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

   mseclog    1
   statefile  ./log/fhem.save
   updateInBackground 1
   userattr   devStateIcon devStateStyle icon sortby webCmd
   verbose    1
   version    $Id: fhem.pl 4769 2014-01-29 08:14:58Z rudolfkoenig $

[sebixvi]

So,

der Logs zweiter Teil. Jetzt habe ich es das erste Mal geschafft, mit fhem eine Temperaturliste an einen RT zu übertragen. Ich habe den Burst-Mode eingeschaltet (laut Wiki burstRX auf on und burstAcces 1_auto). Nach einigen Minuten hat er dann tatsächlich die Liste übernommen. Dazwischen gibt es viele noACKS. Ich verstehe auch nicht, warum die Readings alle auf set_ stehen?!

Insgesamt antwortet der RT häufig mit "nö", wenn fhem ihm Befehle schicken möchte. Aber warum?

Internals:
   DEF        22BBF5
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     39
   NAME       thermostat_az
   NR         31
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_22BBF5_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_22BBF5_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_22BBF5_WindowRec
   channel_04 solltemp_az
   channel_05 CUL_HM_HM_CC_RT_DN_22BBF5_ClimaTeam
   channel_06 CUL_HM_HM_CC_RT_DN_22BBF5_remote
   hmusb_MSGCNT 39
   hmusb_RAWMSG R04871910,0001,008FE42C,FF,FFE0,3C800222BBF542424200
   hmusb_RSSI -32
   hmusb_TIME 2014-02-06 01:09:26
   lastMsg    No:3C - t:02 s:22BBF5 d:424242 00
   protCmdDel 27
   protCmdPend 12 CMDs pending
   protCondBurst off
   protLastRcv 2014-02-06 01:09:26
   protResnd  6 last_at:2014-02-06 01:06:23
   protResndFail 1 last_at:2014-02-05 23:25:31
   protSnd    21 last_at:2014-02-06 01:09:26
   protState  CMDs_pending
   rssi_at_hmusb avg:-40.25 min:-59 max:-30 lst:-32 cnt:39
   rssi_hmusb avg:-45 min:-45 max:-45 lst:-45 cnt:1
   Readings:
     2014-02-06 00:54:09   Activity        alive
     2014-02-06 01:09:26   CommandAccepted yes
     2014-02-03 19:54:03   PairedTo        0x424242
     2014-02-04 00:49:29   R-backOnTime    set_10 s
     2014-02-04 00:49:29   R-btnLock       set_unlock
     2014-02-06 00:55:05   R-burstRx       set_on
     2014-02-04 00:49:29   R-cyclicInfoMsg set_on
     2014-02-04 00:49:29   R-cyclicInfoMsgDis set_0
     2014-02-04 00:49:29   R-globalBtnLock set_off
     2014-02-04 00:49:29   R-localResDis   set_off
     2014-02-04 00:49:29   R-lowBatLimitRT set_2.1 V
     2014-02-04 00:49:29   R-modusBtnLock  set_off
     2014-02-04 00:49:29   R-pairCentral   set_0x424242
     2014-02-05 23:59:15   RegL_07:        CA:11 CB:20 CC:24
     2014-02-06 01:09:25   actuator        0 %
     2014-02-06 01:09:25   battery         ok
     2014-02-06 01:09:25   batteryLevel    3 V
     2014-02-06 01:09:25   desired-temp    9
     2014-02-06 01:09:25   measured-temp   23.3
     2014-02-06 01:09:31   state           CMDs_pending
     Regl_00::
       VAL       
   cmdStack:
     ++A00142424222BBF500040000000000
     ++A00142424222BBF50103
     ++A00142424222BBF501040000000001
     ++A00142424222BBF50203
     ++A00142424222BBF502040000000001
     ++A00142424222BBF50303
     ++A00142424222BBF503040000000001
     ++A00142424222BBF504040000000001
     ++A00142424222BBF500040000000007
     ++A00142424222BBF50503
     ++A00142424222BBF505040000000001
     ++A00142424222BBF50603
     ++A00142424222BBF506040000000001
   Helper:
     cSnd       0142424222BBF500040000000000
     mId        0095
     rxType     140
     Io:
       nextSend   1391645366.62889
     Prt:
       awake      0
       bErr       0
       sProc      2
       sleeping   1
       wakeup     1
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
     Rssi:
       At_hmusb:
         avg        -40.2564102564102
         cnt        39
         lst        -32
         max        -30
         min        -59
       Hmusb:
         avg        -45
         cnt        1
         lst        -45
         max        -45
         min        -45
     Shregw:
       07         04
     Shadowreg:
       RegL_00:   0 01:01
       RegL_07:   
Attributes:
   IODev      hmusb
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   expert     2_full
   firmware   1.2
   model      HM-CC-RT-DN
   peerIDs   
   room       arbeitszimmer
   serialNr   KEQ0727575
   subType    thermostat
   webCmd     :burstXmit

[uland2012]

Moin,

hier mein Beitrag zur "Datenerhebung"

• 1x     Raspberry mit CUL und FHEM (letztes Update gemacht am 05.02.14 morgens)
• 10x   HM-CC-RT-DN FW V1.2
• davon 6 RT in einer Structure
• Alle RT sowie Structure werden über Heating_Control zeitgesteuert vom FHEM betrieben.

Mit dieser Codezeile:       $dDly -= 0.04 if ($mTy eq "02");
hatte ich folgenden Effekt:

• RT hatten blinkende Antenne
• Readings im Device unter FHEM teilweise unvollständig
• motorERR:     communicationERR
• dauerndes wechseln zwischen CMDs_Processing und CMDs-pending (klar war ja communicationERR)

Nach dem deaktivieren der Codezeile:     # $dDly -= 0.04 if ($mTy eq "02");   

• Haben die RT keine blinkende Antenne mehr
• Die Readings in den Devices sind wieder vollständig
• motorERR: OK