Nur Text | Text mit Bildern

FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: franz27 am 29 September 2015, 18:26:50

Titel: [Gelöst] CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 29 September 2015, 18:26:50
Hallo Zusammen,

ich habe im Keller 3 HM-CC-VDs, da der Empfang dort recht schlecht ist, habe ich mir zusätzlich zum Cubiertruck mit einem CUL noch einen HMLAN besorgt, der jetzt auch im Keller hängt.
Den HMLAN habe ich wie im Wiki/Forum beschieben in FHEM eingebunden, und mit assignIO meiner vccu zusätzlich zum CUL hinzugefügt. vccu, CUL und HMLAN haben die selbe HMid.

Dann habe ich die VDs neu gepairt und hier habe ich das erste seltsame verhalten:
Mit 'set vccu pairForSec 60' wird im log ein pair mit dem CUL angezeit,
'set CUL_HM0 pairForSec 60' ebenso,
'set HMLAN1 pairForSec 60' kein pairing möglich.
(Zwischendurch immer Reset am VD und unpair sowie clear all beim Device in FHEM)
Ist das normal, das mit dem HMLAN kein pairing möglich ist?

Nach dem pairing wird automatisch beim Device IOgrp vccu:CUL_HM0 eingetragen, was den HMLAN ja auch schon ausschließt. Das habe ich auf IOgrp vccu geändert. In den Internals bei LASTInputDev steht übrigens der HMLAN1 drin?!?

Die Kommikation mit den VDs läuft auch eher schecht, die virtuellen TCs melden öfter lost als ok. Ich kann bekomme aber kein Protokoll wie in http://forum.fhem.de/index.php/topic,22223.msg158227.html#msg158227 hin, also mit Meldungen wie:
Zitat20:49:01.872  TC1_1  :171  => UPPS!!! 4 sec zu spät. next um  48:57.15 + 171 = 51:48.15

Was mir noch aufgefallen ist, sind Ausreißer bei apptime
Code Auswählen
                               name             function    max  count    total  average maxDly
                             CUL_HM0             CUL_Read   1320  25304  1164701    46.03      0 HASH(CUL_HM0)
                          hz.1g.info readingsGroup_Notify    942  12544     2135     0.17      0 HASH(hz.1g.info); HASH(hz.1g.sz.ht_Clima)
                    hz.ventil.notify          notify_Exec    906  12544    83078     6.62      0 HASH(hz.ventil.notify); HASH(hz.1g.info)
                              HMLAN1           HMLAN_Read    774  26381   216199     8.20      0 HASH(HMLAN1)
                             myDbLog            DbLog_Log    516  12544   764518    60.95      0 HASH(myDbLog); HASH(hz.2g.ventil)
                   hz.maxVent.notify          notify_Exec    410  12544    21055     1.68      0 HASH(hz.maxVent.notify); HASH(hz.1g.status)
              hz.1g.virttc_valveCtrl           CUL_HM_Set    403     61     9991   163.79      0 HASH(hz.1g.virttc_valveCtrl); hz.1g.virttc_valveCtrl; valvePos; 80
              hz.eg.virttc_valveCtrl           CUL_HM_Set    395     38     4999   131.55      0 HASH(hz.eg.virttc_valveCtrl); hz.eg.virttc_valveCtrl; valvePos; 20
              hz.2g.virttc_valveCtrl           CUL_HM_Set    391     34     4200   123.53      0 HASH(hz.2g.virttc_valveCtrl); hz.2g.virttc_valveCtrl; valvePos; 99
Die Durchschnittswerte sehen ok aus, aber es gibt beim max. einge zu hohe Werte. Fhem läuft auf einem Cubietruck, ansonsten ist da nur noch die mysql-Datenbank fürs Log drauf.

Irgendwelche Ideen wo das Problem liegen könnte?

Grüße
Franz
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: Hollo am 29 September 2015, 19:56:26
Zitat von: franz27 am 29 September 2015, 18:26:50
...Den HMLAN habe ich wie im Wiki/Forum beschieben in FHEM eingebunden, und mit assignIO meiner vccu zusätzlich zum CUL hinzugefügt...
Wieso assignIO ???
Du musst den HMLAN definieren und dann als IODev der IOList hinzufügen.
Steht der HMLAN in der IOList Deiner vccu?   Ich vermute nein.

Sinngemäß:
Code Auswählen
attr vccu IOList HMLAN CUL_HM0
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 29 September 2015, 20:15:16
ZitatDann habe ich die VDs neu gepairt
war überflüssig, oder hast du eine neue hmid?

ZitatDas habe ich auf IOgrp vccu geändert.
mit dem cul solltest du es aus timinggründen vermeiden. deshalb besser "IOgrp vccu:HMLAN1".

Zitatdie virtuellen TCs melden öfter lost als ok.
wie gesagt, mit cul eigentlich zu vergessen. eventuell mit der timing optimierten fw aus dem angepinnten thread.

bring dein hmlan zum laufen. was steht im state der vccu?
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 29 September 2015, 21:29:33
Zitat von: Hollo am 29 September 2015, 19:56:26
Wieso assignIO ???
Du musst den HMLAN definieren und dann als IODev der IOList hinzufügen.
Steht der HMLAN in der IOList Deiner vccu?   Ich vermute nein.

Sinngemäß:
Code Auswählen
attr vccu IOList HMLAN CUL_HM0

Habe ich zuerst auch so gemacht, da ich aber die oben beschriebenen Probleme beim pairen hatte, habe ich mit die vccu mal genauer angeschaut und gesehen das unter Internals/assignedIOs nur der CUL aufgeführt war.
Ich habe zwischenzeitlich, auch den HMLAN wieder aus der IOList der vccu raus genommen, die original HMid des HMLAN gesetzt und versucht so zu pairen - hat aber auch nicht geklappt. War auch nur ein Versuch die Abläufe besser zu verstehen.
Bei der vccu habe ich den set assignIO befehl gefunden und einfach mal ausprobiert (ist in der Commandref nicht beschieben), der holt den HMLAN in die vccu (assignedIOs + IOList) und setzt die HMid des HMLAN auf die der vccu, schein mir eine "Komfort"-Funktion zu sein.


@frank
Zitatwar überflüssig, oder hast du eine neue hmid?
Keine neue HMid, aber ich hatte schon einige Zeit experimentiert und wollte aus gleichen Startbedingungen heraus weiter testen, nicht das noch irgendwelche falschen alten Einstellungen in den VDs hängen.

Zitatmit dem cul solltest du es aus timinggründen vermeiden. deshalb besser "IOgrp vccu:HMLAN1".
"IOgrp vccu:HMLAN1" hatte ich auch schon, macht aber keinen Unterschied. Internals/IODef steht bei den Ventilen auf HMLAN1, die Automatik (IO mit dem bestem rssi) scheint da zu funktionieren.

Zitatbring dein hmlan zum laufen. was steht im state der vccu?
Code Auswählen
state CUL_HM0:ok,HMLAN1:ok,
Scheint Ok zu sein.

Hier noch ein List des HMLAN, da erkenne ich aber auch keinen Fehler
Code Auswählen
Internals:
   DEF        xx.xx.xx.xx:1000
   DeviceName xx.xx.xx.xx:1000
   FD         16
   HMLAN1_MSGCNT 61848
   HMLAN1_TIME 2015-09-29 21:18:09
   IFmodel    LAN
   NAME       HMLAN1
   NR         368
   NTFY_ORDER 50-HMLAN1
   PARTIAL
   RAWMSG     E3228F6,0000,26035885,FF,FFA0,1C84703228F600000000C03F
   RSSI       -96
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDsCnt 4
   msgKeepAlive dlyMax:1.043 bufferMin:3
   msgLoadCurrent 9
   msgLoadHistory 5min steps: -1/0/0/0/0/0/0/0/0/1/0/1
   msgParseDly min:-8 max:4635 last:13 cnt:61742
   owner      24CE23
   owner_CCU  vccu
   uptime     007 177:09:13.477
   CHANGETIME:
   Readings:
     2015-09-26 17:17:45   D-HMIdAssigned  24CE23
     2015-09-26 17:17:45   D-HMIdOriginal  2CD637
     2015-09-26 17:17:45   D-firmware      0.964
     2015-09-26 17:17:45   D-serialNr      xxxxxxxx
     2015-09-26 17:17:46   Xmit-Events     ok:1 disconnected:1 init:1
     2015-09-26 17:17:46   cond            ok
     2015-09-29 21:18:08   loadLvl         low
     2015-09-26 17:17:38   prot_disconnected last
     2015-09-26 17:17:38   prot_init       last
     2015-09-26 17:17:46   prot_ok         last
     2015-09-22 06:59:34   prot_timeout    last
     2015-09-26 17:17:38   state           opened
   Helper:
     assIdCnt   4
     assIdRep   4
     info       03C4,LEQ0641479,2CD637,24CE23
     setTime    44053
     Bm:
       Hmlan_get:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Hmlan_notify:
         cnt        14001
         dmx        0
         max        1
         tot        2
         mAr:
           HASH(HMLAN1)
           HASH(hz.1g.sz.ht)
       Hmlan_read:
         cnt        29346
         dmx        0
         max        774
         tot        240375
         mAr:
           HASH(HMLAN1)
       Hmlan_set:
         cnt        71
         dmx        0
         mAr
         max        0
         tot        0
     Cnd:
       0          1
       253        1
       255        1
     Dly:
       cnt        61742
       lst        13
       max        4635
       min        -8
     Ids:
       1e6da0:
         chn        00
         flg        0
         name       hz.eg.ventil
       1e71a0:
         chn        00
         flg        0
         msg
         name       hz.1g.ventil
         to         1443551217.57764
       204323:
         chn        00
         flg        0
         msg
         name       hz.2g.ventil
         to         1443550523.25798
       2d9928:
         name       hz.temp
     K:
       BufMin     3
       DlyMax     1.043
       Next       1443554313.74281
       Start      1443554288.74281
     Loadlvl:
       bl         40
       a:
         99
         90
         40
         0
       H:
         0          low
         40         batchLevel
         90         high
         99         suspended
     Log:
       all        0
       sys        0
       ids:
         1E6DA0
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLast   8
       loadNo     3
       scnt       0
       apIDs:
     Ref:
       drft       -0.000199984001279898
       hmtL       637752980
       kTs        0
       offL       1442916535766
       sysL       1443554288746
Attributes:
   DbLogExclude .*
   hmId       24CE23
   hmLanQlen  1_min
   icon       hm_lan
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   logIDs     hz.eg.ventil
   room       CUL_HM

Ich habe den Eindruck, dass der HMLAN nur empfängt, aber irgendwie nicht sendet, zumindest nicht an die VDs.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 29 September 2015, 21:50:56
poste mal die lists von deinem virtuellen tc. es könnte auch sein, dass das dort eingetragene io für das senden verantwortlich ist.

auf alle fälle mal sniffen, wie im wiki angegeben. am besten mit beiden io.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 29 September 2015, 22:00:45
List der virtuellen TCs

Code Auswählen
Internals:
   CUL_HM0_MSGCNT 1394
   CUL_HM0_RAWMSG A0B02A25822CE001E6DA00000::-81:CUL_HM0
   CUL_HM0_RSSI -81
   CUL_HM0_TIME 2015-09-29 21:54:17
   DEF        22CE00
   HMLAN1_MSGCNT 1354
   HMLAN1_RAWMSG E22CE00,0000,25FF3987,FF,FFB3,F2A25822CE001E6DA00000
   HMLAN1_RSSI -77
   HMLAN1_TIME 2015-09-29 21:13:39
   IODev      HMLAN1
   LASTInputDev CUL_HM0
   MSGCNT     2748
   NAME       hz.eg.virttc
   NR         371
   NTFY_ORDER 50-hz.eg.virttc
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 hz.eg.virttc_valveCtrl
   lastMsg    No:02 - t:58 s:22CE00 d:1E6DA0 0000
   protLastRcv 2015-09-29 21:54:17
   protSnd    1 last_at:2015-09-26 17:20:13
   protState  CMDs_done
   rssi_at_CUL_HM0 avg:-78.12 min:-83.5 max:-72 lst:-81 cnt:1394
   rssi_at_HMLAN1 avg:-78.35 min:-105 max:-72 lst:-77 cnt:1354
   CHANGETIME:
   Readings:
     2015-09-26 17:20:13   CommandAccepted yes
     2015-09-26 17:20:13   state           CMDs_done
   Helper:
     HM_CMDNR   2
     PONtest    1
     Bm:
       Cul_hm_attr:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Cul_hm_get:
         cnt        3
         dmx        0
         mAr
         max        0
         tot        0
       Cul_hm_set:
         cnt        18
         dmx        0
         max        1
         tot        2
         mAr:
           HASH(hz.eg.virttc)
           hz.eg.virttc
           ?
     Io:
       nextSend   1443556457.21006
       vccu       vccu
     Mrssi:
       mNo        02
       Io:
         CUL_HM0    -81
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul_hm0:
         avg        -78.1230272596844
         cnt        1394
         lst        -81
         max        -72
         min        -83.5
       At_hmlan1:
         avg        -78.3530280649926
         cnt        1354
         lst        -77
         max        -72
         min        -105
Attributes:
   DbLogExclude .*
   IOgrp      vccu
   event-on-update-reading state
   expert     2_full
   model      virtual_1
   msgRepeat  0
   room       TC,vccu
   subType    virtual

Code Auswählen
Internals:
   CUL_HM0_MSGCNT 5542
   CUL_HM0_RAWMSG A0B3FA25822CE011E71A00000::-79.5:CUL_HM0
   CUL_HM0_RSSI -79.5
   CUL_HM0_TIME 2015-09-29 21:57:34
   DEF        22CE01
   HMLAN1_MSGCNT 45
   HMLAN1_RAWMSG E22CE01,0000,258F23A1,FF,FFA8,FEA25822CE011E71A000CC
   HMLAN1_RSSI -88
   HMLAN1_TIME 2015-09-29 19:11:14
   IODev      HMLAN1
   LASTInputDev CUL_HM0
   MSGCNT     5587
   NAME       hz.1g.virttc
   NR         369
   NTFY_ORDER 50-hz.1g.virttc
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 hz.1g.virttc_valveCtrl
   lastMsg    No:3F - t:58 s:22CE01 d:1E71A0 0000
   protLastRcv 2015-09-29 21:57:34
   rssi_at_CUL_HM0 avg:-78.72 min:-106.5 max:-71 lst:-79.5 cnt:5542
   rssi_at_HMLAN1 avg:-77.39 min:-89 max:-73 lst:-88 cnt:45
   Readings:
     2015-09-25 15:43:13   CommandAccepted yes
     2015-09-25 15:43:13   state           CMDs_done
   Helper:
     HM_CMDNR   63
     PONtest    1
     Bm:
       Cul_hm_attr:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Cul_hm_get:
         cnt        5
         dmx        0
         mAr
         max        0
         tot        0
       Cul_hm_set:
         cnt        20
         dmx        0
         max        3
         tot        5
         mAr:
           HASH(0x23ff748)
           hz.1g.virttc
           ?
     Io:
       nextSend   1443556654.51653
       vccu       vccu
     Mrssi:
       mNo        3F
       Io:
         CUL_HM0    -79.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul_hm0:
         avg        -78.7278058462651
         cnt        5542
         lst        -79.5
         max        -71
         min        -106.5
       At_hmlan1:
         avg        -77.4
         cnt        45
         lst        -88
         max        -73
         min        -89
Attributes:
   DbLogExclude .*
   IOgrp      vccu
   event-on-update-reading state
   expert     2_full
   model      virtual_1
   msgRepeat  0
   room       TC,vccu
   subType    virtual

Code Auswählen
Internals:
   CUL_HM0_MSGCNT 5452
   CUL_HM0_RAWMSG A0B9AA25822CE022043230033::-81:CUL_HM0
   CUL_HM0_RSSI -81
   CUL_HM0_TIME 2015-09-29 21:57:05
   DEF        22CE02
   HMLAN1_MSGCNT 42
   HMLAN1_RAWMSG E22CE02,0000,25847D68,FF,FFA9,55A25822CE0220432300CC
   HMLAN1_RSSI -87
   HMLAN1_TIME 2015-09-29 18:59:37
   IODev      HMLAN1
   LASTInputDev CUL_HM0
   MSGCNT     5494
   NAME       hz.2g.virttc
   NR         373
   NTFY_ORDER 50-hz.2g.virttc
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 hz.2g.virttc_valveCtrl
   lastMsg    No:9A - t:58 s:22CE02 d:204323 0033
   protLastRcv 2015-09-29 21:57:05
   rssi_at_CUL_HM0 avg:-78.69 min:-107.5 max:-71 lst:-81 cnt:5452
   rssi_at_HMLAN1 avg:-76.28 min:-87 max:-72 lst:-87 cnt:42
   Readings:
     2015-09-23 18:39:39   CommandAccepted yes
     2015-09-23 18:39:39   state           CMDs_done
   Helper:
     HM_CMDNR   154
     PONtest    1
     Bm:
       Cul_hm_attr:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Cul_hm_get:
         cnt        6
         dmx        0
         max        2
         tot        2
         mAr:
           HASH(0x1f6f090)
           hz.2g.virttc
           ?
       Cul_hm_set:
         cnt        21
         dmx        0
         max        1
         tot        3
         mAr:
           HASH(hz.2g.virttc)
           hz.2g.virttc
           ?
     Io:
       nextSend   1443556625.70457
       vccu       vccu
     Mrssi:
       mNo        9A
       Io:
         CUL_HM0    -81
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul_hm0:
         avg        -78.6995597945706
         cnt        5452
         lst        -81
         max        -71
         min        -107.5
       At_hmlan1:
         avg        -76.2857142857143
         cnt        42
         lst        -87
         max        -72
         min        -87
Attributes:
   DbLogExclude .*
   IOgrp      vccu
   event-on-update-reading state
   expert     2_full
   model      virtual_1
   msgRepeat  0
   room       TC,vccu
   subType    virtual


Lese micht gerade bei der CUL-Firmware mit den Timingänderungen ein.
Sniffen werde ich morgen.

Danke.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 30 September 2015, 08:22:38
So, jetzt ist morgen :)

Im Anhang die gesnifften Daten (mit attr CUL_HM0 verbose 4 und attr HMLAN1 logIDs sys,all)

Die HMids der Ventile sind 1E6DA0, 1E71A0, 204323, die virtuellen TCs 22CE00, 22CE01, 22CE02.

Bei 204323 (hz.2g....) war am Ende des Protokolls die Kommunikation ok, bei 1E71A0 (hz.1g....) nicht.

Gibt es eigentlich hier oder im Wiki eine Beschreibung wie die Informationen der HM-Botschaften zu interpretieren sind? Ich habe nichts gefunden.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: Hollo am 30 September 2015, 09:08:28
Zitat von: franz27 am 29 September 2015, 21:29:33
...
Hier noch ein List des HMLAN, da erkenne ich aber auch keinen Fehler
Code Auswählen
Internals:
   DEF        xx.xx.xx.xx:1000
   DeviceName xx.xx.xx.xx:1000
   FD         16
   HMLAN1_MSGCNT 61848
   HMLAN1_TIME 2015-09-29 21:18:09
   IFmodel    LAN
   NAME       HMLAN1
   NR         368
   NTFY_ORDER 50-HMLAN1
   PARTIAL
   RAWMSG     E3228F6,0000,26035885,FF,FFA0,1C84703228F600000000C03F
   RSSI       -96
   STATE      opened
   TYPE       HMLAN
   XmitOpen   1
   assignedIDsCnt 4
   msgKeepAlive dlyMax:1.043 bufferMin:3
   msgLoadCurrent 9
   msgLoadHistory 5min steps: -1/0/0/0/0/0/0/0/0/1/0/1
   msgParseDly min:-8 max:4635 last:13 cnt:61742
   owner      24CE23
   owner_CCU  vccu
   uptime     007 177:09:13.477
   CHANGETIME:
   Readings:
     2015-09-26 17:17:45   D-HMIdAssigned  24CE23
     2015-09-26 17:17:45   D-HMIdOriginal  2CD637
     2015-09-26 17:17:45   D-firmware      0.964
     2015-09-26 17:17:45   D-serialNr      xxxxxxxx
     2015-09-26 17:17:46   Xmit-Events     ok:1 disconnected:1 init:1
     2015-09-26 17:17:46   cond            ok
     2015-09-29 21:18:08   loadLvl         low
     2015-09-26 17:17:38   prot_disconnected last
     2015-09-26 17:17:38   prot_init       last
     2015-09-26 17:17:46   prot_ok         last
     2015-09-22 06:59:34   prot_timeout    last
     2015-09-26 17:17:38   state           opened
   Helper:
     assIdCnt   4
     assIdRep   4
     info       03C4,LEQ0641479,2CD637,24CE23
     setTime    44053
     Bm:
       Hmlan_get:
         cnt        1
         dmx        0
         mAr
         max        0
         tot        0
       Hmlan_notify:
         cnt        14001
         dmx        0
         max        1
         tot        2
         mAr:
           HASH(HMLAN1)
           HASH(hz.1g.sz.ht)
       Hmlan_read:
         cnt        29346
         dmx        0
         max        774
         tot        240375
         mAr:
           HASH(HMLAN1)
       Hmlan_set:
         cnt        71
         dmx        0
         mAr
         max        0
         tot        0
     Cnd:
       0          1
       253        1
       255        1
     Dly:
       cnt        61742
       lst        13
       max        4635
       min        -8
     Ids:
       1e6da0:
         chn        00
         flg        0
         name       hz.eg.ventil
       1e71a0:
         chn        00
         flg        0
         msg
         name       hz.1g.ventil
         to         1443551217.57764
       204323:
         chn        00
         flg        0
         msg
         name       hz.2g.ventil
         to         1443550523.25798
       2d9928:
         name       hz.temp
     K:
       BufMin     3
       DlyMax     1.043
       Next       1443554313.74281
       Start      1443554288.74281
     Loadlvl:
       bl         40
       a:
         99
         90
         40
         0
       H:
         0          low
         40         batchLevel
         90         high
         99         suspended
     Log:
       all        0
       sys        0
       ids:
         1E6DA0
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLast   8
       loadNo     3
       scnt       0
       apIDs:
     Ref:
       drft       -0.000199984001279898
       hmtL       637752980
       kTs        0
       offL       1442916535766
       sysL       1443554288746
Attributes:
   DbLogExclude .*
   hmId       24CE23
   hmLanQlen  1_min
   icon       hm_lan
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   logIDs     hz.eg.ventil
   room       CUL_HM

Ich habe den Eindruck, dass der HMLAN nur empfängt, aber irgendwie nicht sendet, zumindest nicht an die VDs.
Wenn da ein rssi von -96 steht, wird da auch nicht viel passieren; vor allem wenn Du den dann noch als preferred IO definierst.  :o
Bei den Devices reicht erstmal ein "IOgrp vccu", dann nehmen die automatisch das mit der besten "Erreichbarkeit".
Guck mal nach, warum Dein HMLAN so miserable Werte hat; platziere denn mal an andere Stellen und guck nach der Veränderung des rssi-Wertes.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 30 September 2015, 10:24:22
Zitat von: Hollo am 30 September 2015, 09:08:28
Wenn da ein rssi von -96 steht, wird da auch nicht viel passieren; vor allem wenn Du den dann noch als preferred IO definierst.  :o
Bei den Devices reicht erstmal ein "IOgrp vccu", dann nehmen die automatisch das mit der besten "Erreichbarkeit".
Guck mal nach, warum Dein HMLAN so miserable Werte hat; platziere denn mal an andere Stellen und guck nach der Veränderung des rssi-Wertes.

Das ist wahrscheinlich der rssi der letzten empfangenen Botschaft einem anderen Gerät das eher im 2. Stock als im Keller ist.
Die rssi mit den Geräten im Keller sind gut:
Code Auswählen

hz.eg.ventil    HMLAN1          hz.eg.ventil     -56.0  -56.0  -59.0< -55.0   463
hz.eg.ventil    hz.eg.ventil    HMLAN1           -50.0  -49.3  -50.0< -49.0   280
hz.1g.ventil    HMLAN1          hz.1g.ventil     -54.0  -53.9  -55.0< -53.0  1298
hz.1g.ventil    hz.1g.ventil    HMLAN1           -48.0  -47.8  -48.0< -47.0   599
hz.2g.ventil    HMLAN1          hz.2g.ventil     -55.0  -54.8  -56.0< -54.0  1342
hz.2g.ventil    hz.2g.ventil    HMLAN1           -48.0  -47.9  -50.0< -47.0   827
hz.temp         HMLAN1          hz.temp          -52.0  -52.1  -54.0< -52.0  2102
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 30 September 2015, 10:49:53
grundsätzlich sendet der hmlan doch. aber wie gesagt, setze ihn beim virtuellen tc und im vd als preffered io. ab und zu funkt der cul dazwischen.

gepaired sind alle vd. aber irgendwelche daten vermisst fhem. beim automatischen getconfig gibt es dann wohl regelmässig kommunikationsprobleme, da fhem, vd und vtc durcheinander "quatschen". ist dein fhem tagesaktuell? anschliessend ist das timing hinüber. erst nach ca 75 minuten (vd war eingeschlafen) gibt es die nächste kommunikation.

also mach mal mit jedem vd ein getconfig und hole die befehle manuell ab (taste am vd drücken). wenn die getconfig funktioniert haben (cmds_done), mach ein save. danach sollten die vd laufen.

Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 30 September 2015, 14:39:29
Zitat von: frank am 30 September 2015, 10:49:53
grundsätzlich sendet der hmlan doch. aber wie gesagt, setze ihn beim virtuellen tc und im vd als preffered io. ab und zu funkt der cul dazwischen.

gepaired sind alle vd. aber irgendwelche daten vermisst fhem. beim automatischen getconfig gibt es dann wohl regelmässig kommunikationsprobleme, da fhem, vd und vtc durcheinander "quatschen". ist dein fhem tagesaktuell? anschliessend ist das timing hinüber. erst nach ca 75 minuten (vd war eingeschlafen) gibt es die nächste kommunikation.

also mach mal mit jedem vd ein getconfig und hole die befehle manuell ab (taste am vd drücken). wenn die getconfig funktioniert haben (cmds_done), mach ein save. danach sollten die vd laufen.

OK, IOgrp steht bei VDs und vTCs auf vccu:HMLAN1, getConfig usw. habe ich gemacht.
Jetzt ist es 3 Stunden später, aber eine Verbesserung kann ich nicht erkennen.

"get vccu listDevice" zeigt:
Code Auswählen

devices using vccu
current IO / preferred
  ....
  HMLAN1 / --- hz.temp
  HMLAN1 / HMLAN1 hz.1g.ventil
  HMLAN1 / HMLAN1 hz.1g.virttc
  HMLAN1 / HMLAN1 hz.2g.ventil
  HMLAN1 / HMLAN1 hz.2g.virttc
  HMLAN1 / HMLAN1 hz.eg.ventil
  HMLAN1 / HMLAN1 hz.eg.virttc


Allerdings meldet "get HMLAN assignIDs" nur
Code Auswählen

assignedIDs: 4
1E71A0 : hz.1g.ventil
204323 : hz.2g.ventil
1E6DA0 : hz.eg.ventil
2D9928 : hz.temp

Da fehlen die vTCs. Internals/assignedIDsCnt ist 4, das passt dazu.
Kann ich die vTCs irgendwie manuell dieser Liste zufügen?

Gibt es für den CUL auch einen analogen Befehl um die zugewiesenen Devices anzuzeigen?
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 30 September 2015, 15:19:25
ZitatGibt es für den CUL auch einen analogen Befehl um die zugewiesenen Devices anzuzeigen?
nein

poste mal ein "get hminfo configCheck" und die lists der vd's

edit:
ZitatAllerdings meldet "get HMLAN assignIDs" nur
das passt schon.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 30 September 2015, 16:34:26
Zitat von: frank am 30 September 2015, 15:19:25
poste mal ein "get hminfo configCheck" und die lists der vd's

Jeckerweise hat sich wohl bei dem getConfig auf den VDs von heute Mittag bei dem einen Ventil (hz.2g.ventil) die ID vom pairedTo und R-pairCentral geändert, bleibt auch nach erneutem getConfig so stehen (3 CMDs pending -> Anlerntaste -> CMDs done). Ich habe mal gegrept, die id F8CE89 taucht nirgendwo in der config auf. In der Nachbarschaft setzt auch niemand Homematic ein.
Das Beste ist aber, daß das betroffene Ventil zur Zeit Kommunikation ok hat (bzw. der vTC zum Ventil) und auf der richtigen Position steht.

"get hm configCheck"
Code Auswählen

configCheck done:

PairedTo mismatch to IODev
    hz.2g.ventil paired:0xF8CE89 IO attr: 24CE23.


Code Auswählen
Internals:
   CUL_HM0_MSGCNT 94
   CUL_HM0_RAWMSG A0A9B80021E6DA024CE2300::-70.5:CUL_HM0
   CUL_HM0_RSSI -70.5
   CUL_HM0_TIME 2015-09-30 16:08:57
   DEF        1E6DA0
   HMLAN1_MSGCNT 94
   HMLAN1_RAWMSG R1E95ACB4,0001,2A0ECE80,FF,FFC7,9B80021E6DA024CE2300
   HMLAN1_RSSI -57
   HMLAN1_TIME 2015-09-30 16:08:57
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     188
   NAME       hz.eg.ventil
   NR         375
   NTFY_ORDER 50-hz.eg.ventil
   STATE      90
   TYPE       CUL_HM
   lastMsg    No:9B - t:02 s:1E6DA0 d:24CE23 00
   peerList   hz.eg.virttc_valveCtrl,
   protCmdDel 28
   protCmdPend 2 CMDs pending
   protLastRcv 2015-09-30 16:08:57
   protResnd  28 last_at:2015-09-30 16:16:25
   protResndFail 7 last_at:2015-09-30 16:03:25
   protSnd    108 last_at:2015-09-30 16:16:24
   protState  CMDs_pending
   rssi_HMLAN1 avg:-50 min:-55 max:-49 lst:-50 cnt:71
   rssi_at_CUL_HM0 avg:-70.3 min:-80 max:-69 lst:-70.5 cnt:94
   rssi_at_HMLAN1 avg:-56.1 min:-61 max:-55 lst:-57 cnt:94
   CHANGETIME:
   Helper:
     Dblog:
       Valvedesired:
         Mydblog:
           TIME       1443617998.51317
           VALUE      40
       Valveposition:
         Mydblog:
           TIME       1443622132.64754
           VALUE      90
       Operstate:
         Mydblog:
           TIME       1443622133.34396
           VALUE      errorTargetNotMet
       Operstateerrcnt:
         Mydblog:
           TIME       1443622136.79345
           VALUE      78
   Readings:
     2015-09-30 12:17:46   Activity        alive
     2015-09-30 16:08:57   CommandAccepted yes
     2015-09-30 12:17:46   D-firmware      2.0
     2015-09-30 12:17:46   D-serialNr      JEQ0729299
     2015-09-30 12:09:56   PairedTo        0x24CE23
     2015-09-30 12:09:56   R-pairCentral   0x24CE23
     2015-09-30 08:29:34   R-valveErrorPos 90 %
     2015-09-26 16:44:42   R-valveOffset   0 %
     2015-09-30 12:09:56   RegL_00:        02:01 0A:24 0B:CE 0C:23 00:00
     2015-09-30 12:17:49   RegL_05:         09:00 0A:5A 00:00
     2015-09-30 14:59:58   ValveDesired    40 %
     2015-09-30 16:08:56   ValvePosition   90
     2015-09-30 16:08:56   battery         ok
     2015-09-30 16:08:56   motor           stop
     2015-09-30 16:08:56   motorErr        ok
     2015-09-30 16:08:56   operState       errorTargetNotMet
     2015-09-30 16:08:56   operStateErrCnt 78
     2015-09-30 12:15:47   peerList        hz.eg.virttc_valveCtrl,
     2015-09-30 12:05:44   powerOn         2015-09-30 12:05:44
     2015-09-30 16:08:56   recentStateType ack
     2015-09-30 16:08:56   state           90
   cmdStack:
     ++A25822CE001E6DA00066
     ++A25822CE001E6DA00066
     ++A25822CE001E6DA00066
   Helper:
     HM_CMDNR   155
     mId        003A
     oldDes     40
     rxType     12
     Io:
       newChn     +1E6DA0,02,00,00
       nextSend   1443622137.88897
       rxt        2
       vccu       vccu
       p:
         1E6DA0
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        9B
       Io:
         CUL_HM0    -70.5
         HMLAN1     -55
     Prt:
       bErr       0
       sProc      2
       sleeping   1
       wuReSent   4
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlan1:
         avg        -50
         cnt        71
         lst        -50
         max        -49
         min        -55
       At_cul_hm0:
         avg        -70.3031914893617
         cnt        94
         lst        -70.5
         max        -69
         min        -80
       At_hmlan1:
         avg        -56.1063829787234
         cnt        94
         lst        -57
         max        -55
         min        -61
     Shadowreg:
Attributes:
   DbLogExclude Activity,motor.*,openState.*,powerOn,state,battery,Valve.*:1800
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_full
   firmware   2.0
   model      HM-CC-VD
   peerIDs    00000000,22CE0001,
   room       Heizung,Heizung_EG,TC
   serialNr   JEQ0729299
   subType    thermostat
   verbose    5
   webCmd     getConfig:clear msgEvents

Code Auswählen
Internals:
   CUL_HM0_MSGCNT 83
   CUL_HM0_RAWMSG A0AE380021E71A024CE2300::-66:CUL_HM0
   CUL_HM0_RSSI -66
   CUL_HM0_TIME 2015-09-30 15:34:08
   DEF        1E71A0
   HMLAN1_MSGCNT 86
   HMLAN1_RAWMSG R1E75C81C,0001,29EEEB1D,FF,FFCA,E380021E71A024CE2300
   HMLAN1_RSSI -54
   HMLAN1_TIME 2015-09-30 15:34:08
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     169
   NAME       hz.1g.ventil
   NR         373
   NTFY_ORDER 50-hz.1g.ventil
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:E3 - t:02 s:1E71A0 d:24CE23 00
   peerList   hz.1g.virttc_valveCtrl,
   protCmdDel 72
   protLastRcv 2015-09-30 15:34:08
   protResnd  65 last_at:2015-09-30 16:17:16
   protResndFail 18 last_at:2015-09-30 16:14:30
   protSnd    128 last_at:2015-09-30 16:17:13
   protState  CMDs_pending
   rssi_HMLAN1 avg:-48.15 min:-51 max:-48 lst:-48 cnt:38
   rssi_at_CUL_HM0 avg:-65.54 min:-66.5 max:-63.5 lst:-66 cnt:83
   rssi_at_HMLAN1 avg:-54.43 min:-62 max:-54 lst:-54 cnt:86
   CHANGETIME:
   Helper:
     Dblog:
       Valvedesired:
         Mydblog:
           TIME       1443621765.80444
           VALUE      99
       Valveposition:
         Mydblog:
           TIME       1443620043.54775
           VALUE      90
       Operstate:
         Mydblog:
           TIME       1443620043.54775
           VALUE      errorTargetNotMet
       Operstateerrcnt:
         Mydblog:
           TIME       1443620047.3193
           VALUE      403
   Readings:
     2015-09-30 12:17:53   Activity        alive
     2015-09-30 15:34:07   CommandAccepted yes
     2015-09-30 12:17:53   D-firmware      2.0
     2015-09-30 12:17:53   D-serialNr      JEQ0728290
     2015-09-30 12:17:55   PairedTo        0x24CE23
     2015-09-25 15:41:36   R-pairCentral   0x24CE23
     2015-09-25 15:42:11   R-valveErrorPos 90 %
     2015-09-25 15:41:36   R-valveOffset   0 %
     2015-09-30 12:17:55   RegL_00:          02:01 0A:24 0B:CE 0C:23 00:00
     2015-09-30 12:17:56   RegL_05:          09:00 0A:5A 00:00
     2015-09-30 16:02:45   ValveDesired    99 %
     2015-09-30 15:34:07   ValvePosition   90
     2015-09-30 15:34:07   battery         ok
     2015-09-30 15:34:07   motor           stop
     2015-09-30 15:34:07   motorErr        ok
     2015-09-30 15:34:07   operState       errorTargetNotMet
     2015-09-30 15:34:07   operStateErrCnt 403
     2015-09-30 12:17:56   peerList        hz.1g.virttc_valveCtrl,
     2015-09-30 15:34:07   recentStateType ack
     2015-09-30 16:14:30   state           MISSING ACK
   cmdStack:
     ++A25822CE011E71A000FD
   Helper:
     HM_CMDNR   227
     cSnd       0124CE231E71A00103,0124CE231E71A001040000000005
     mId        003A
     oldDes     0
     peerIDsRaw ,22CE0101,00000000,B9
     rxType     12
     Io:
       newChn     +1E71A0,00,00,00
       nextSend   1443620048.41685
       rxt        2
       vccu       vccu
       p:
         1E71A0
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        E3
       Io:
         CUL_HM0    -66
         HMLAN1     -52
     Prt:
       bErr       0
       sProc      2
       wuReSent   2
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlan1:
         avg        -48.1578947368421
         cnt        38
         lst        -48
         max        -48
         min        -51
       At_cul_hm0:
         avg        -65.5421686746988
         cnt        83
         lst        -66
         max        -63.5
         min        -66.5
       At_hmlan1:
         avg        -54.4302325581395
         cnt        86
         lst        -54
         max        -54
         min        -62
     Shadowreg:
Attributes:
   DbLogExclude Activity,motor.*,openState.*,powerOn,state,battery,Valve.*:1800
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_full
   firmware   2.0
   model      HM-CC-VD
   peerIDs    00000000,22CE0101,
   room       Heizung,Heizung_1G,TC
   serialNr   JEQ0728290
   subType    thermostat
   webCmd     getConfig:clear msgEvents

Code Auswählen
Internals:
   CUL_HM0_MSGCNT 84
   CUL_HM0_RAWMSG A0E4C820220432322CE020101A00030::-65.5:CUL_HM0
   CUL_HM0_RSSI -65.5
   CUL_HM0_TIME 2015-09-30 16:17:25
   DEF        204323
   HMLAN1_MSGCNT 85
   HMLAN1_RAWMSG E204323,0000,2A168E4C,FF,FFC9,4C820220432322CE020101A00030
   HMLAN1_RSSI -55
   HMLAN1_TIME 2015-09-30 16:17:25
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     169
   NAME       hz.2g.ventil
   NR         374
   NTFY_ORDER 50-hz.2g.ventil
   STATE      80
   TYPE       CUL_HM
   lastMsg    No:4C - t:02 s:204323 d:22CE02 0101A00030
   peerList   hz.2g.virttc_valveCtrl,
   protCmdDel 60
   protLastRcv 2015-09-30 16:17:25
   protResnd  53 last_at:2015-09-30 16:07:16
   protResndFail 15 last_at:2015-09-30 16:02:20
   protSnd    121 last_at:2015-09-30 16:17:24
   protState  CMDs_done
   rssi_HMLAN1 avg:-47.88 min:-48 max:-46 lst:-48 cnt:45
   rssi_at_CUL_HM0 avg:-65.1 min:-67 max:-64 lst:-65.5 cnt:84
   rssi_at_HMLAN1 avg:-54.87 min:-57 max:-52 lst:-55 cnt:85
   CHANGETIME:
   Helper:
     Dblog:
       Valvedesired:
         Mydblog:
           TIME       1443621778.82116
           VALUE      80
       Valveposition:
         Mydblog:
           TIME       1443622161.1783
           VALUE      80
       Operstate:
         Mydblog:
           TIME       1443622161.1783
           VALUE      onTarget
       Operstateerrcnt:
         Mydblog:
           TIME       1443622036.41707
           VALUE      470
   Readings:
     2015-09-30 16:09:12   Activity        alive
     2015-09-30 16:17:25   CommandAccepted yes
     2015-09-30 16:09:12   D-firmware      2.0
     2015-09-30 16:09:12   D-serialNr      KEQ0087447
     2015-09-30 16:09:12   PairedTo        0xF8CE89
     2015-09-30 12:05:56   R-pairCentral   0xF8CE89
     2015-09-23 18:35:11   R-valveErrorPos 90 %
     2015-09-23 18:33:41   R-valveOffset   0 %
     2015-09-30 16:09:12   RegL_00:          02:01 0A:F8 0B:CE 0C:89 00:00
     2015-09-30 16:09:13   RegL_05:          09:00 0A:5A 00:00
     2015-09-30 16:02:58   ValveDesired    80 %
     2015-09-30 16:17:25   ValvePosition   80
     2015-09-30 16:17:25   battery         ok
     2015-09-30 16:17:25   motor           stop
     2015-09-30 16:17:25   motorErr        ok
     2015-09-30 16:17:25   operState       onTarget
     2015-09-30 16:07:16   operStateErrCnt 470
     2015-09-30 16:09:12   peerList        hz.2g.virttc_valveCtrl,
     2015-09-25 16:14:19   powerOn         2015-09-25 16:14:19
     2015-09-30 16:17:25   recentStateType ack
     2015-09-30 16:17:25   state           80
   Helper:
     HM_CMDNR   76
     cSnd       0124CE232043230103,0124CE2320432301040000000005
     mId        003A
     oldDes     80
     peerIDsRaw ,22CE0201,00000000,4F
     rxType     12
     Io:
       newChn     +204323,00,00,00
       nextSend   1443622645.65385
       rxt        2
       vccu       vccu
       p:
         204323
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        4C
       Io:
         CUL_HM0    -65.5
         HMLAN1     -53
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       Hmlan1:
         avg        -47.8888888888889
         cnt        45
         lst        -48
         max        -46
         min        -48
       At_cul_hm0:
         avg        -65.1011904761905
         cnt        84
         lst        -65.5
         max        -64
         min        -67
       At_hmlan1:
         avg        -54.8705882352941
         cnt        85
         lst        -55
         max        -52
         min        -57
     Shadowreg:
Attributes:
   DbLogExclude Activity,motor.*,openState.*,powerOn,state,battery,Valve.*:1800
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_full
   firmware   2.0
   model      HM-CC-VD
   peerIDs    00000000,22CE0201,
   room       Heizung,Heizung_2G,TC
   serialNr   KEQ0087447
   subType    thermostat
   webCmd     getConfig:clear msgEvents


Nachtrag:
Ich hatte fhem vor ein paar Tagen aktualisiert, heute aber auch nochmal.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 30 September 2015, 17:22:00
ZitatJeckerweise hat sich wohl bei dem getConfig auf den VDs von heute Mittag bei dem einen Ventil (hz.2g.ventil) die ID vom pairedTo und R-pairCentral geändert, bleibt auch nach erneutem getConfig so stehen (3 CMDs pending -> Anlerntaste -> CMDs done). Ich habe mal gegrept, die id F8CE89 taucht nirgendwo in der config auf. In der Nachbarschaft setzt auch niemand Homematic ein.
seltsam. wenn es wirklich mit der id gepaired ist, funktioniert kein getconfig mehr. eigentlich gar nichts mehr. also am besten reset und neu pairen. befehle immer manuell über den taster abholen.

ZitatDas Beste ist aber, daß das betroffene Ventil zur Zeit Kommunikation ok hat (bzw. der vTC zum Ventil) und auf der richtigen Position steht.
das passt schon, da es ja mit dem vtc gepeered ist.

funktionieren denn die anderen nun?
wie sehen die messages aus?

alle 2-3 minuten muss eine erfolgreiche kommunikation erscheinen
Code Auswählen
2015.09.29 22:49:20.430 0: HMLAN_Send:  HMLAN1 S:S1ADDE37D stat:  00 t:00000000 d:01 r:1ADDE37D m:AF A258 22CE02 204323 0033
2015.09.29 22:49:20.961 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2656D88D d:FF r:FFC9     m:AF 8202 204323 22CE02 0101280030
2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 R:R1ADDE37D stat:0008 t:00000000 d:FF r:7FFF     m:AF A258 22CE02 204323 0033
2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 no ACK from 204323


wenn der vd eingeschlafen ist (antennensymbol blinkt), wacht er von selbst nach ca 75min dauerhaft auf, wodurch eine erneute synchronisation möglich wird. wenn du bei blinkender antenne einmal kurz den taster drückst, wacht er auch auf und sollte nach ca 3 min ebenfalls synchronisieren.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 01 Oktober 2015, 08:04:10
Zitat von: frank am 30 September 2015, 17:22:00
funktionieren denn die anderen nun?
wie sehen die messages aus?
Nein, keine Besserung. Ich schaue mir mal an, ob die Kommunikation zu dem von Dir angegebenen Muster passt.

Zitat von: frank am 30 September 2015, 17:22:00
alle 2-3 minuten muss eine erfolgreiche kommunikation erscheinen
Code Auswählen
2015.09.29 22:49:20.430 0: HMLAN_Send:  HMLAN1 S:S1ADDE37D stat:  00 t:00000000 d:01 r:1ADDE37D m:AF A258 22CE02 204323 0033
2015.09.29 22:49:20.961 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2656D88D d:FF r:FFC9     m:AF 8202 204323 22CE02 0101280030
2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 R:R1ADDE37D stat:0008 t:00000000 d:FF r:7FFF     m:AF A258 22CE02 204323 0033
2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 no ACK from 204323

Muss die letzte Zeile so sein (no ACK), oder ist das ein Kommunikationsfehler?
Ich verstehe es so: Zeile 1 und 2, HMLAN sendet an VD, Antwort vom VD.
Aber wer ist der Sender in Zeile 3?

Nachtrag:
Wenn, wie Du beschreibst, bei mir alles durcheinander sendet, wäre es eine Möglichkeit die vTCs ganz zu löschen, fhem neu zu starten und die dann wieder anzulegen?
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 01 Oktober 2015, 15:56:21
ZitatIch verstehe es so: Zeile 1 und 2, HMLAN sendet an VD, Antwort vom VD.
vielleicht.

Zitat2015.09.29 22:49:20.430 0: HMLAN_Send:  HMLAN1 S:S1ADDE37D stat:  00 t:00000000 d:01 r:1ADDE37D m:AF A258 22CE02 204323 0033
1. vtc => vd. braun: message nr, rot: command type, blau: sender, grün: empfänger, rest: payload.

Zitat2015.09.29 22:49:20.961 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2656D88D d:FF r:FFC9     m:AF 8202 204323 22CE02 0101280030
2. antwort vd => vtc

Zitat2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 R:R1ADDE37D stat:0008 t:00000000 d:FF r:7FFF     m:AF A258 22CE02 204323 0033
3. vermutlich das ack des hmlan an fhem (sendebestätigung). ist im prinzip die sendemsg.

Zitat2015.09.29 22:49:20.966 0: HMLAN_Parse: HMLAN1 no ACK from 204323
4. kommt immer, da hmlan unter falscher hmid (vtc) sendet und es dafür natürlich kein ack an die zentrale gab.

ich habe 5 vd erfolgreich am laufen mit hmlan und fritzbox. pro vd habe ich eventuell 5 einzelne miss in 24 stunden. also eine msg wird nicht beantwortet, aber die folgenden sind wieder ok. lost gibt es eigentlich gar nicht. nur wenn ich viel mit fhem arbeite.

es gibt einen thread tc emulieren. da sollte alles drinstehen.

ZitatWenn, wie Du beschreibst, bei mir alles durcheinander sendet, wäre es eine Möglichkeit die vTCs ganz zu löschen, fhem neu zu starten und die dann wieder anzulegen?
dann muss fhem noch mehr infos ordern. eher schlecht. aber probieren geht über studieren. einen musst du doch eh neu pairen, dachte icht.
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 02 Oktober 2015, 10:52:36
Hallo frank,

danke für Deine Hinweise, damit komme ich jetzt zumindest mit der Analyse besser klar. Richtig laufen tut es immer noch nicht.
Die Message-Nr. ist wohl eher als "Gesprächs"-Nr. zu verstehen und kennzeichnet zusammenhgehörige Nachrichten.

Das hier ist ein erstes ok nach einem längern Zeitraum mit miss. Das sieht auch immer ähnlich aus, mit 5 verschiendenen Message-Nr., hier F5, D9, F6, F7, F8.
Dabei ist die zweite Message-Nr. immer einiges kleiner als die erste, der Rest ist fortlaufend, wobei die D9, F6 und F8-Messages vom HMLAN kommen, F5 und F7 vom vTC.
Der Payload ist auch jeweils immer gleich.
Zitat
2015.10.01 10:14:49.753 0: HMLAN_Send:  HMLAN1 S:S2277D4E9 stat:  00 t:00000000 d:01 r:2277D4E9 m:F5 A258 22CE02 204323 00CC
2015.10.01 10:14:49.758 0: HMLAN_Send:  HMLAN1 I:+204323,02,00,00
2015.10.01 10:14:50.015 0: HMLAN_Send:  HMLAN1 S:S2277D590 stat:  00 t:00000000 d:01 r:2277D590 m:D9 A112 24CE23 204323
2015.10.01 10:14:50.214 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF11DEA d:FF r:FFC9     m:F5 8202 204323 22CE02 0101B40030
2015.10.01 10:14:50.498 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF11EE3 d:FF r:FFC9     m:F5 8002 204323 24CE23 00
2015.10.01 10:14:50.513 0: HMLAN_Parse: HMLAN1 R:R226C967E stat:0008 t:00000000 d:FF r:7FFF     m:F5 A112 24CE23 204323
2015.10.01 10:14:50.514 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:50.712 0: HMLAN_Send:  HMLAN1 S:S2277D849 stat:  00 t:00000000 d:01 r:2277D849 m:F6 A112 24CE23 204323
2015.10.01 10:14:50.908 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF120A3 d:FF r:FFC9     m:F5 8202 204323 22CE02 0101B40030
2015.10.01 10:14:51.202 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF1219C d:FF r:FFCA     m:F5 8002 204323 24CE23 00
2015.10.01 10:14:51.223 0: HMLAN_Parse: HMLAN1 R:R226C967E stat:0008 t:00000000 d:FF r:7FFF     m:F5 A112 24CE23 204323
2015.10.01 10:14:51.224 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:51.507 0: HMLAN_Send:  HMLAN1 S:S2277DBC3 stat:  00 t:00000000 d:01 r:2277DBC3 m:F6 A112 24CE23 204323
2015.10.01 10:14:51.510 0: HMLAN_Parse: HMLAN1 R:R2277D4E9 stat:0008 t:00000000 d:FF r:7FFF     m:F5 A258 22CE02 204323 00CC
2015.10.01 10:14:51.511 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:51.511 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF1235D d:FF r:FFC9     m:F5 8202 204323 22CE02 0101B40030
2015.10.01 10:14:51.857 0: HMLAN_Parse: HMLAN1 R:R1425C324 stat:0081 t:2DF1245A d:FF r:FFC9     m:F5 8002 204323 24CE23 00
2015.10.01 10:14:51.968 0: HMLAN_Parse: HMLAN1 R:R2277D590 stat:0001 t:2DF125EC d:FF r:FFC9     m:D9 8002 204323 24CE23 00
2015.10.01 10:14:52.463 0: HMLAN_Send:  HMLAN1 S:S2277DF21 stat:  00 t:00000000 d:01 r:2277DF21 m:F7 A258 22CE02 204323 00CC
2015.10.01 10:14:52.469 0: HMLAN_Parse: HMLAN1 R:R2277D849 stat:0001 t:2DF12781 d:FF r:FFC9     m:F6 8002 204323 24CE23 00
2015.10.01 10:14:52.870 0: HMLAN_Send:  HMLAN1 S:S2277E0B7 stat:  00 t:00000000 d:01 r:2277E0B7 m:F8 A112 24CE23 204323
2015.10.01 10:14:53.066 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF12912 d:FF r:FFC9     m:F7 8202 204323 22CE02 0101B40030
2015.10.01 10:14:53.070 0: HMLAN_Parse: HMLAN1 R:R2277DBC3 stat:0008 t:00000000 d:FF r:7FFF     m:F6 A112 24CE23 204323
2015.10.01 10:14:53.070 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:53.191 0: HMLAN_Parse: HMLAN1 R:R226C967E stat:0081 t:2DF12A10 d:FF r:FFC9     m:F7 8002 204323 24CE23 00
2015.10.01 10:14:53.526 0: HMLAN_Send:  HMLAN1 S:S2277E347 stat:  00 t:00000000 d:01 r:2277E347 m:F8 A112 24CE23 204323
2015.10.01 10:14:53.721 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF12BA2 d:FF r:FFC9     m:F7 8202 204323 22CE02 0101B40030
2015.10.01 10:14:53.976 0: HMLAN_Parse: HMLAN1 R:R226C967E stat:0081 t:2DF12CA0 d:FF r:FFC9     m:F7 8002 204323 24CE23 00
2015.10.01 10:14:54.183 0: HMLAN_Send:  HMLAN1 S:S2277E5D7 stat:  00 t:00000000 d:01 r:2277E5D7 m:F8 A112 24CE23 204323
2015.10.01 10:14:54.376 0: HMLAN_Parse: HMLAN1 R:R2277DF21 stat:0008 t:00000000 d:FF r:7FFF     m:F7 A258 22CE02 204323 00CC
2015.10.01 10:14:54.376 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:54.377 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF12E33 d:FF r:FFC9     m:F7 8202 204323 22CE02 0101B40030
2015.10.01 10:14:54.485 0: HMLAN_Parse: HMLAN1 R:R1425C324 stat:0081 t:2DF12F31 d:FF r:FFC9     m:F7 8002 204323 24CE23 00
2015.10.01 10:14:54.739 0: HMLAN_Send:  HMLAN1 I:+204323,00,00,00
2015.10.01 10:14:54.744 0: HMLAN_Parse: HMLAN1 R:R2277E347 stat:0001 t:2DF130C2 d:FF r:FFC9     m:F8  8 8002 204323 24CE23 00
2015.10.01 10:14:54.806 0: HMLAN_Parse: HMLAN1 R:R2277E0B7 stat:0008 t:00000000 d:FF r:7FFF     m:F8 A112 24CE23 204323
2015.10.01 10:14:54.806 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:14:55.210 0: HMLAN_Parse: HMLAN1 R:R2277E5D7 stat:0001 t:2DF13298 d:FF r:FFC9     m:F8 8002 204323 24CE23 00

Hier ein zweites ok
Zitat
2015.10.01 10:16:56.754 0: HMLAN_Send:  HMLAN1 S:S2279C501 stat:  00 t:00000000 d:01 r:2279C501 m:F6 A258 22CE02 204323 00CC
2015.10.01 10:16:57.285 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF30E16 d:FF r:FFC9     m:F6 8202 204323 22CE02 0101A00030
2015.10.01 10:16:57.289 0: HMLAN_Parse: HMLAN1 R:R2279C501 stat:0008 t:00000000 d:FF r:7FFF     m:F6 A258 22CE02 204323 00CC
2015.10.01 10:16:57.290 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:16:57.304 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF30F80 d:FF r:FFC9     m:F6 8202 204323 22CE02 0101A00030

und ein drittes
Zitat
2015.10.01 10:19:53.256 0: HMLAN_Send:  HMLAN1 S:S227C7678 stat:  00 t:00000000 d:01 r:227C7678 m:F7 A258 22CE02 204323 00CC
2015.10.01 10:19:53.842 0: HMLAN_Parse: HMLAN1 R:R227C7678 stat:0008 t:00000000 d:FF r:7FFF     m:F7 A258 22CE02 204323 00CC
2015.10.01 10:19:53.842 0: HMLAN_Parse: HMLAN1 no ACK from 204323
2015.10.01 10:19:53.843 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF5C145 d:FF r:FFC9     m:F7 8202 204323 22CE02 0101A00030

dann das folgende miss
Zitat
2015.10.01 10:22:35.258 0: HMLAN_Send:  HMLAN1 S:S227EEF49 stat:  00 t:00000000 d:01 r:227EEF49 m:F8 A258 22CE02 204323 00CC
2015.10.01 10:22:35.864 0: HMLAN_Parse: HMLAN1 R:R227EEF49 stat:0008 t:00000000 d:FF r:7FFF     m:F8 A258 22CE02 204323 00CC
2015.10.01 10:22:35.865 0: HMLAN_Parse: HMLAN1 no ACK from 204323

Ich habe mir auch den Quellcode zu in den FHEM Dateien angeschaut, A258 ist das Wakeup von Fhem/vTC an den VD, 8202 die "Jo, bin wach"-Antwort vom VD, 8002 (in diesem Fall mit 00) ein ACK vom VD.

Was mich sehr irritiert ist das beim ersten OK alles 4 mal gesendet wird, bei den zweien (F5 und F7) kommt ein ACK vom VD - kein Wunder, daß danach die Timer nicht stimmen, welcher von den beiden soll denn als Basis für die weitere Kommunikation genommen werden. Meistens kommt danach auch direkt wieder ein miss und es dauert eine Stunde bis zum nächsten OK.

Kann ich auch irgendwie die Timings protokollieren, also wann Fhem/vTC meinen die nächste Botschaft senden zu müssen und ob der Sendezeitpunkt dann auch passt?
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 02 Oktober 2015, 11:43:21
ZitatWas mich sehr irritiert ist das beim ersten OK alles 4 mal gesendet wird, bei den zweien (F5 und F7) kommt ein ACK vom VD - kein Wunder, daß danach die Timer nicht stimmen, welcher von den beiden soll denn als Basis für die weitere Kommunikation genommen werden. Meistens kommt danach auch direkt wieder ein miss und es dauert eine Stunde bis zum nächsten OK.
das meinte ich mit "durcheinanderquatschen".
vtc und die zentrale (fhem) wollen infos.

Code Auswählen
2015.10.01 10:14:50.015 0: HMLAN_Send:  HMLAN1 S:S2277D590 stat:  00 t:00000000 d:01 r:2277D590 m:D9 A112 24CE23 204323
zentrale sendet hallo wach, ich habe was zu melden

Code Auswählen
2015.10.01 10:14:50.498 0: HMLAN_Parse: HMLAN1 R:E204323   stat:0000 t:2DF11EE3 d:FF r:FFC9     m:F5 8002 204323 24CE23 00
es kommt auch eine antwort (ack) an die zentrale. aber die msgnummer stimmt nicht. normalerweise wird mit der selben nummer geantwortet. somit scheint die antwort in fhem nicht richtig zugeordnet zu werden, denn es wird weiterhin das hallo wach wiederholt anstatt mit der eigentlichen message zu starten. wahrscheinlich getconfig.

ich sehe gerade dass ich bei mir im vd das attr msgRepeat=0 gesetzt habe. das solltest du auch tun.
trotzdem bleibt die frage, was will die zentrale? hast du erfolgreich manuell getconfig durchgeführt? in hminfo gibt es keine auffälligkeiten?

trotz der langwierigen kommunikation, wurde aber das nächste kommunikationsfenster erfolgreich berechnet und gefunden. unter anderem wird die aktuelle msgnummer einer erfolgreichen kommunikation zur berechnung des nächsten fensters benutzt. ist der vd nach dem miss dann eingeschlafen? wenn der vd einschläft, obwohl es kein durcheinanderquatschen gab, müsste eigentlich fhem einen erheblichen freeze gehabt haben. lass doch mal das modul perfmon laufen.

ZitatKann ich auch irgendwie die Timings protokollieren, also wann Fhem/vTC meinen die nächste Botschaft senden zu müssen und ob der Sendezeitpunkt dann auch passt?
verbose=5 beim vtc_chn

du könntest ja mal meine versionen probieren. vielleicht hat sich ein fehler eingeschlichen.
Zitat# $Id: 10_CUL_HM.pm 9173 2015-08-30 16:11:11Z martinp876 $
# $Id: 00_HMLAN.pm 9103 2015-08-22 05:23:08Z martinp876 $
# $Id: HMConfig.pm 9172 2015-08-30 15:54:59Z martinp876 $
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 02 Oktober 2015, 13:08:30
Zitat von: frank am 02 Oktober 2015, 11:43:21
ich sehe gerade dass ich bei mir im vd das attr msgRepeat=0 gesetzt habe. das solltest du auch tun.
Das scheints gewesen zu sein, läuft seit ca. 45 min stabil. 1x bei einem vTC miss_1 dann direkt wieder ok. Ist noch zu früh für eine definitive Aussage, aber sieht sehr gut aus.

Vielen Dank Frank - bekommst ein Bier von mir, falls wir uns mal über den Weg laufen sollten :)
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 02 Oktober 2015, 13:40:36
ZitatDas scheints gewesen zu sein
na dann, prost!

sind die A112 messages dadurch jetzt komplett verschwunden, oder sind die nur auswirkungen "moderater"?

Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: franz27 am 02 Oktober 2015, 14:10:36
Zitat von: frank am 02 Oktober 2015, 13:40:36
sind die A112 messages dadurch jetzt komplett verschwunden, oder sind die nur auswirkungen "moderater"?

Die sind weg, die letzte war von 12:37.

Ich habe noch was zum Thema msgRepeat gelesen um das Verhalten zu verstehen:
Der HMLAN macht von sich aus bei Kommunikationsproblemen bis zu 3 Wiederholungen, wenn bei dem VD msgRepeat=0 nicht gesetzt ist, sendet Fhem selbst auch Wiederholungen und dann haben wir einen großen Haufen Wiederholungen die alle völlig unabhänig durcheinander funken.
Richtig?
Titel: Antw:CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 02 Oktober 2015, 14:48:23
ZitatRichtig?
fast.

das attr msgRepeat sollte die anzahl der wiederholungen der befehle auf dieses device sein.
also zb bei einem statusrequest auf einen aktor erhält fhem keine antwort, dann wird msgrepeat mal wiederholt, bis eine antwort kommt. wenn das attribut fehlt, ist msgrepeat=3. hier ist es natürlich entsprechend komplizierter. eigentlich dürfte sich die zentrale hier gar nicht einmischen, wenn die zentrale gar nichts will.

ich denke, dass die "no ack" meldungen, die auch bei erfolgreicher kommunikation zwischen vtc und vd auftauchen, wahrscheinlich dann die ursache für die A112 messages sind. diese "falschen" no-ack infos, die der hmlan an fhem sendet, müssten in fhem wahrscheinlich "umgebucht" werden. fhem weiss ja, dass es eine antwort vom vd an den vtc gab, obwohl der hmlan anderer meinung ist.

wäre gut, wenn martin dazu noch etwas einfallen könnte.
Titel: Antw:[Gelöst] CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: martinp876 am 03 Oktober 2015, 17:43:47
msgRepeat sind die Wiederholungen von FHEM. HMLAN macht - wie korrekt gesehen, selbst 3. Wenn man also msgRepeat 5 einstellt werden 3*5 messages gesendet.
Die Wiederholungen von FHEM sind deutlich Langsamer und deken einen anderen Level ab. Bei Schaltern hat sich das positiv ausgewirkt. Beides ergänzt sich.

Bei Burst devices und den wakeups sollte man es auf 0 setzen.

Die HMLAN Wiederholungen kann ich nicht ändern.
Titel: Antw:[Gelöst] CUL + HMLAN / Unzuverlässiges Verhalten von HM-CC-VD mit virtuellem TC
Beitrag von: frank am 04 Oktober 2015, 13:14:05
hallo martin,

ZitatmsgRepeat sind die Wiederholungen von FHEM. HMLAN macht - wie korrekt gesehen, selbst 3. Wenn man also msgRepeat 5 einstellt werden 3*5 messages gesendet.
Die Wiederholungen von FHEM sind deutlich Langsamer und deken einen anderen Level ab. Bei Schaltern hat sich das positiv ausgewirkt. Beides ergänzt sich.
es geht definitiv um fhem wiederholungen. hier ein log mit msgrepeat=0 beim vd und vtc. nach einem miss ist die nächste kommunikation ganz normal.

Code Auswählen
2015.10.04 12:58:53.132 0: HMLAN_Send:  hmlan1 S:S32811B9A stat:  00 t:00000000 d:01 r:32811B9A m:85 A258 B2B2B2 1DFC2F 00FD
2015.10.04 12:58:53.174 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:00316966 d:FF r:FFDD     m:85 A258 B2B2B2 1DFC2F 00FD
2015.10.04 12:58:53.398 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:00316A2E d:FF r:FFDD     m:85 A258 B2B2B2 1DFC2F 00FD
2015.10.04 12:58:53.590 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:00316AF6 d:FF r:FFDD     m:85 A258 B2B2B2 1DFC2F 00FD
2015.10.04 12:58:53.702 0: HMLAN_Parse: hmlan1 R:R32811B9A stat:0008 t:00000000 d:FF r:7FFF     m:85 A258 B2B2B2 1DFC2F 00FD
2015.10.04 12:58:53.704 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 12:58:53.709 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:17C2FB7C d:FF r:FFD1     m:85 8202 1DFC2F B2B2B2 0101C6002D
2015.10.04 12:58:53.750 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:00316B78 d:FF r:FFCB     m:85 8202 1DFC2F B2B2B2 0101C6002D
2015.10.04 12:59:22.181 1: Perfmon: possible freeze starting at 12:59:21, delay is 1.181
2015.10.04 13:01:16.149 1: Perfmon: possible freeze starting at 13:01:15, delay is 1.148
2015.10.04 13:01:16.156 0: HMLAN_Send:  hmlan1 S:S32834A4A stat:  00 t:00000000 d:01 r:32834A4A m:86 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:01:17.218 0: HMLAN_Parse: hmlan1 R:R32834A4A stat:0008 t:00000000 d:FF r:7FFF     m:86 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:01:17.221 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 13:01:17.239 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:00339813 d:FF r:FFDD     m:86 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:01:17.258 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:003398DB d:FF r:FFDD     m:86 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:01:17.272 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:003399A3 d:FF r:FFDD     m:86 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:02:11.297 1: Perfmon: possible freeze starting at 13:02:10, delay is 1.297
2015.10.04 13:02:24.095 1: Perfmon: possible freeze starting at 13:02:23, delay is 1.095
2015.10.04 13:03:22.886 0: HMLAN_Send:  hmlan1 S:S32853954 stat:  00 t:00000000 d:01 r:32853954 m:87 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:03:22.929 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:0035871C d:FF r:FFDD     m:87 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:03:23.153 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:003587E4 d:FF r:FFDD     m:87 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:03:23.277 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:17C71891 d:FF r:FFD1     m:87 8202 1DFC2F B2B2B2 0101C6002D
2015.10.04 13:03:23.451 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:00358868 d:FF r:FFCB     m:87 8202 1DFC2F B2B2B2 0101C6002D
2015.10.04 13:03:23.468 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:00358885 d:FF r:FFDD     m:87 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:03:23.483 0: HMLAN_Parse: hmlan1 R:R32853954 stat:0008 t:00000000 d:FF r:7FFF     m:87 A258 B2B2B2 1DFC2F 00FD
2015.10.04 13:03:23.485 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F


wenn ich aber msgrepeat=3 beim vd einschalte (msgrepeat=0 beim vtc), funkt hier ständig die zentrale mit A112 dazwischen, obwohl eigentlich nichts zu tun wäre. auch die A258 messages des vtc werden wiederholt.

warum erscheinen die A112 messages, wenn msgrepeat gesetzt ist?

Code Auswählen
2015.10.04 10:52:40.162 0: HMLAN_Send:  hmlan1 S:S320D8DB0 stat:  00 t:00000000 d:01 r:320D8DB0 m:53 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:52:40.214 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D58804 d:FF r:FFDD     m:53 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:52:40.343 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04D58886 d:FF r:FFCA     m:53 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:52:40.385 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:174F67FD d:FF r:FFD0     m:53 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:52:40.402 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D588A4 d:FF r:FFDD     m:53 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:52:40.566 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D5896B d:FF r:FFDD     m:53 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:52:40.732 0: HMLAN_Parse: hmlan1 R:R320D8DB0 stat:0008 t:00000000 d:FF r:7FFF     m:53 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:52:40.734 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 10:55:19.418 0: HMLAN_Send:  hmlan1 S:S320FFBC9 stat:  00 t:00000000 d:01 r:320FFBC9 m:54 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:55:19.475 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D7F619 d:FF r:FFDD     m:54 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:55:19.667 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D7F6E1 d:FF r:FFDD     m:54 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:55:19.859 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04D7F7A9 d:FF r:FFDD     m:54 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:55:20.028 0: HMLAN_Parse: hmlan1 R:R320FFBC9 stat:0008 t:00000000 d:FF r:7FFF     m:54 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:55:20.030 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 10:55:55.623 1: ----- SYNC-ITR1500 ----- FB_IT02_chn01:off => IT07:off
2015.10.04 10:57:44.169 0: HMLAN_Send:  hmlan1 S:S32123136 stat:  00 t:00000000 d:01 r:32123136 m:55 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:44.209 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA2B86 d:FF r:FFDD     m:55 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:44.433 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA2C4F d:FF r:FFDD     m:55 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:44.539 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:17540C76 d:FF r:FFD0     m:55 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:44.634 0: HMLAN_Send:  hmlan1 S:S321232B9 stat:  00 t:00000000 d:01 r:321232B9 m:54 A112 1ACE1F 1DFC2F
2015.10.04 10:57:44.664 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA2CD2 d:FF r:FFCA     m:55 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:44.689 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA2D49 d:FF r:FFDD     m:55 A112 1ACE1F 1DFC2F
2015.10.04 10:57:44.785 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:17540D6C d:FF r:FFD0     m:55 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:44.817 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA2DC8 d:FF r:FFCA     m:55 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:45.075 0: HMLAN_Parse: hmlan1 R:R31BBC64D stat:0008 t:00000000 d:FF r:7FFF     m:55 A112 1ACE1F 1DFC2F
2015.10.04 10:57:45.078 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 10:57:45.137 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA2F09 d:FF r:FFDD     m:55 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:45.237 0: HMLAN_Parse: hmlan1 R:R32123136 stat:0008 t:00000000 d:FF r:7FFF     m:55 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:45.240 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 10:57:45.245 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:17540F31 d:FF r:FFD0     m:55 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:45.332 0: HMLAN_Send:  hmlan1 S:S3212357B stat:  00 t:00000000 d:01 r:3212357B m:56 A112 1ACE1F 1DFC2F
2015.10.04 10:57:45.362 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA2F8D d:FF r:FFCA     m:55 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:45.378 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3004 d:FF r:FFDD     m:55 A112 1ACE1F 1DFC2F
2015.10.04 10:57:45.484 0: HMLAN_Parse: hmlan1 R:R00000000 stat:0081 t:1754102D d:FF r:FFD0     m:55 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:45.511 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3083 d:FF r:FFCA     m:55 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:45.777 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3194 d:FF r:FFDD     m:54 A112 1ACE1F 1DFC2F
2015.10.04 10:57:45.884 0: HMLAN_Parse: hmlan1 R:R321232B9 stat:0001 t:175411BD d:FF r:FFD0     m:54 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:45.910 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3213 d:FF r:FFCA     m:54 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:46.161 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3327 d:FF r:FFDD     m:56 A112 1ACE1F 1DFC2F
2015.10.04 10:57:46.287 0: HMLAN_Parse: hmlan1 R:R3212357B stat:0001 t:1754134F d:FF r:FFD0     m:56 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:46.385 0: HMLAN_Send:  hmlan1 S:S32123991 stat:  00 t:00000000 d:01 r:32123991 m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:46.412 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA33A6 d:FF r:FFCB     m:56 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:46.577 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA34BA d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:46.695 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:175414E2 d:FF r:FFD0     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:46.801 0: HMLAN_Send:  hmlan1 S:S32123B27 stat:  00 t:00000000 d:01 r:32123B27 m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:46.830 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA353D d:FF r:FFCA     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:46.849 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA35B5 d:FF r:FFDD     m:57 A112 1ACE1F 1DFC2F
2015.10.04 10:57:46.940 0: HMLAN_Parse: hmlan1 R:R31BBC64D stat:0081 t:175415DD d:FF r:FFD0     m:57 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:46.966 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3633 d:FF r:FFCA     m:57 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:47.217 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA3745 d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:47.346 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:1754176D d:FF r:FFD0     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:47.451 0: HMLAN_Send:  hmlan1 S:S32123DB0 stat:  00 t:00000000 d:01 r:32123DB0 m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:47.494 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA37C8 d:FF r:FFCA     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:47.512 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3840 d:FF r:FFDD     m:57 A112 1ACE1F 1DFC2F
2015.10.04 10:57:47.591 0: HMLAN_Parse: hmlan1 R:R31BBC64D stat:0081 t:17541868 d:FF r:FFD0     m:57 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:47.619 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA38BE d:FF r:FFCA     m:57 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:47.889 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DA39D0 d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:47.921 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA39F9 d:FF r:FFDD     m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:48.004 0: HMLAN_Parse: hmlan1 R:R32123991 stat:0008 t:00000000 d:FF r:7FFF     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:57:48.006 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 10:57:48.019 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3A53 d:FF r:FFCA     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:48.057 0: HMLAN_Parse: hmlan1 R:E1DFC2F   stat:0000 t:175419F8 d:FF r:FFD0     m:57 8202 1DFC2F B2B2B2 010100002D
2015.10.04 10:57:48.273 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3B65 d:FF r:FFDD     m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:48.305 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3B7A d:FF r:FFDD     m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:48.399 0: HMLAN_Parse: hmlan1 R:R32123B27 stat:0001 t:17541B8F d:FF r:FFD0     m:58 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:48.423 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3BE5 d:FF r:FFCA     m:58 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:48.689 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:04DA3CF8 d:FF r:FFDD     m:58 A112 1ACE1F 1DFC2F
2015.10.04 10:57:48.801 0: HMLAN_Parse: hmlan1 R:R32123DB0 stat:0001 t:17541D22 d:FF r:FFD0     m:58 8002 1DFC2F 1ACE1F 00
2015.10.04 10:57:48.820 0: HMLAN_Parse: hmusb1 R:E1DFC2F   stat:0000 t:04DA3D77 d:FF r:FFCA     m:58 8002 1DFC2F 1ACE1F 00
2015.10.04 10:59:54.674 0: HMLAN_Send:  hmlan1 S:S32142F01 stat:  00 t:00000000 d:01 r:32142F01 m:56 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:59:54.734 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DC294C d:FF r:FFDD     m:56 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:59:54.926 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DC2A15 d:FF r:FFDD     m:56 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:59:55.125 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DC2ADE d:FF r:FFDD     m:56 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:59:55.284 0: HMLAN_Parse: hmlan1 R:R32142F01 stat:0008 t:00000000 d:FF r:7FFF     m:56 A258 B2B2B2 1DFC2F 0000
2015.10.04 10:59:55.286 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 11:00:35.249 1: Perfmon: possible freeze starting at 11:00:29, delay is 6.247
2015.10.04 11:02:54.674 0: HMLAN_Send:  hmlan1 S:S3216EE20 stat:  00 t:00000000 d:01 r:3216EE20 m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 11:02:54.731 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DEE86D d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 11:02:55.319 0: HMLAN_Parse: hmlan1 R:R3216EE20 stat:0008 t:00000000 d:FF r:7FFF     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 11:02:55.321 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
2015.10.04 11:02:55.324 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DEE935 d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 11:02:55.337 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04DEE9FD d:FF r:FFDD     m:57 A258 B2B2B2 1DFC2F 0000
2015.10.04 11:05:40.182 0: HMLAN_Send:  hmlan1 S:+1DFC2F,02,00,00
2015.10.04 11:05:40.187 0: HMLAN_Send:  hmlan1 S:S321974A2 stat:  00 t:00000000 d:01 r:321974A2 m:58 A258 B2B2B2 1DFC2F 0300
2015.10.04 11:05:40.234 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04E16EF1 d:FF r:FFDD     m:58 A258 B2B2B2 1DFC2F 0300
2015.10.04 11:05:40.457 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04E16FB9 d:FF r:FFDD     m:58 A258 B2B2B2 1DFC2F 0300
2015.10.04 11:05:40.649 0: HMLAN_Parse: hmusb1 R:EB2B2B2   stat:0000 t:04E17081 d:FF r:FFDD     m:58 A258 B2B2B2 1DFC2F 0300
2015.10.04 11:05:40.796 0: HMLAN_Parse: hmlan1 R:R321974A2 stat:0008 t:00000000 d:FF r:7FFF     m:58 A258 B2B2B2 1DFC2F 0300
2015.10.04 11:05:40.798 0: HMLAN_Parse: hmlan1 no ACK from 1DFC2F
Nur Text | Text mit Bildern