HM virtual CCU

martinp876 · 04 Mai 2014, 19:53:48

hm - vielleicht geht es doch einfacher mit dem VD
teste einmal

      elsif(  ($vc ne "init" && $hashVd->{msgRed} <= $hashVd->{miss})
            || $hash->{helper}{virtTC} ne "00") {
          $hashVd->{msgSent} = 1;
#          CUL_HM_PushCmdStack($hash,sprintf("%02X%s%s%s"
          CUL_HM_SndCmd($hashVd,sprintf("%02X%s%s%s"
                                             ,$msgCnt
                                             ,$hashVd->{cmd}
                                             ,$hash->{helper}{virtTC}
                                             ,$hashVd->{val}));
      }
      InternalTimer($tn+10,"CUL_HM_valvePosTmr","valveTmr:$vId",0);
    }
    elsif ($hashVd->{typ} == 2){
#      CUL_HM_PushCmdStack($hash,sprintf("%02X%s%s"
      CUL_HM_SndCmd($hashVd,sprintf("%02X%s%s"
                                        ,$msgCnt
                                        ,$hashVd->{cmd}
                                        ,$hashVd->{val}));
      $hashVd->{next} = $hashVd->{nextM};
      InternalTimer($hashVd->{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);

müsste eigentlich funktionieren. Auch einmal ein getConfig zwischendurch mitschicken. Wenns passt, geht es so "raus"

frank · 04 Mai 2014, 20:36:51

hier einmal ein log vom hmusb mit msgloadest um170%

Code Auswählen

2014.05.03 21:18:27.034 0: HMLAN_Send:  hmusb1 S:SC385F51D stat:  00 t:00000000 d:01 r:C385F51D m:18 A258 B2B2B2 1DFC2F 0000
2014.05.03 21:18:27.706 0: HMLAN_Parse: hmusb1 R:RC385F51D stat:0008 t:00000000 d:FF r:7FFF     m:18 A258 B2B2B2 1DFC2F 0000

2014.05.03 21:18:55.384 0: HMLAN_Send:  hmusb1 S:+1CE9F5,00,01,1E
2014.05.03 21:18:55.387 0: HMLAN_Send:  hmusb1 S:SC38663DB stat:  00 t:00000000 d:01 r:C38663DB m:2E A258 B4B4B4 1CE9F5 0082
2014.05.03 21:18:56.141 0: HMLAN_Parse: hmusb1 R:RC38663DB stat:0008 t:00000000 d:FF r:7FFF     m:2E A258 B4B4B4 1CE9F5 0082
2014.05.03 21:18:56.144 0: HMLAN_Parse: hmusb1 no ACK from 1CE9F5

2014.05.03 21:20:05.105 0: HMLAN_Send:  hmusb1 S:+193A9A,00,01,1E
2014.05.03 21:20:05.108 0: HMLAN_Send:  hmusb1 S:SC3877434 stat:  00 t:00000000 d:01 r:C3877434 m:56 A258 B3B3B3 193A9A 039C
2014.05.03 21:20:05.543 0: HMLAN_Send:  hmusb1 S:SC38775EA stat:  00 t:00000000 d:01 r:C38775EA m:56 A258 B1B1B1 1BFC52 00FD
2014.05.03 21:20:05.788 0: HMLAN_Parse: hmusb1 R:RC3877434 stat:0008 t:00000000 d:FF r:7FFF     m:56 A258 B3B3B3 193A9A 039C
2014.05.03 21:20:05.791 0: HMLAN_Parse: hmusb1 no ACK from 193A9A
2014.05.03 21:20:06.169 0: HMLAN_Parse: hmusb1 R:RC38775EA stat:0008 t:00000000 d:FF r:7FFF     m:56 A258 B1B1B1 1BFC52 00FD
2014.05.03 21:20:06.171 0: HMLAN_Parse: hmusb1 no ACK from 1BFC52

das von eben. da läuft wohl alles rund. zum vergleich.

Code Auswählen

2014.05.04 20:00:56.626 0: HMLAN_Send:  hmusb1 I:K
2014.05.04 20:00:56.681 0: HMLAN_Parse: hmusb1 V:03BC sNo:JEQ0121054 d:1ACE1F O:123ABC t:03666A1B IDcnt:0004
2014.05.04 20:00:58.935 0: HMLAN_Send:  hmusb1 S:SC8656453 stat:  00 t:00000000 d:01 r:C8656453 m:FB 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 20:00:59.114 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:03E5E28A d:FF r:FFC0     m:FB A258 1DFDA5 D2D2D2 0000
2014.05.04 20:00:59.133 0: HMLAN_Parse: hmlan1 R:ED2D2D2   stat:0000 t:03E5E31C d:FF r:FFE6     m:FB 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 20:00:59.208 0: HMLAN_Parse: hmusb1 R:E1DFDA5   stat:0000 t:0366729F d:FF r:FFC0     m:FB A258 1DFDA5 D2D2D2 0000
2014.05.04 20:00:59.222 0: HMLAN_Parse: hmusb1 R:RC8656453 stat:0002 t:00000000 d:FF r:7FFF     m:FB 8002 D2D2D2 1DFDA5 0101000000
2014.05.04 20:00:59.249 0: HMLAN_Parse: hmlan1 R:E1D252E   stat:0000 t:03E5E416 d:FF r:FFC6     m:69 A258 1D252E D1D1D1 00C1
2014.05.04 20:00:59.336 0: HMLAN_Send:  hmusb1 S:SC86565F4 stat:  00 t:00000000 d:01 r:C86565F4 m:69 8002 D1D1D1 1D252E 0101960000
2014.05.04 20:00:59.509 0: HMLAN_Parse: hmusb1 R:E1D252E   stat:0000 t:0366742B d:FF r:FFC0     m:69 A258 1D252E D1D1D1 00C1
2014.05.04 20:00:59.523 0: HMLAN_Parse: hmusb1 R:RC86565F4 stat:0002 t:00000000 d:FF r:7FFF     m:69 8002 D1D1D1 1D252E 0101960000
2014.05.04 20:00:59.610 0: HMLAN_Parse: hmlan1 R:ED1D1D1   stat:0000 t:03E5E4BC d:FF r:FFE6     m:69 8002 D1D1D1 1D252E 0101960000

den vd teste ich gleich noch. es gibt auch noch sonderfall 2. realer tc <=> vvd.

frank · 04 Mai 2014, 22:13:51

hallo martin,

die änderung in cul_hm funktioniert wohl einwandfrei. auch ein getconfig mit msgreduce=2 hat ohne probleme und ohne anlerntaste funktioniert.

ist es so, dass durch diese änderung nun das iodev im "attr ioDev" des vd für die gesamte kommunikation zuständig ist. unabhängig von der einstellung beim vtc?

edit: msgload ist jetzt aber von durschnittlich 6% auf 0% gesunken. iodev ist sowohl bei vtc, als auch vd, hmlan.

gruss frank

martinp876 · 05 Mai 2014, 08:01:17

Zitatist es so, dass durch diese änderung nun das iodev im "attr ioDev" des vd für die gesamte kommunikation zuständig ist. unabhängig von der einstellung beim vtc?

Die vtc messages werden "auf Kosten" des Empfänger gesendet. In diesem Fall ist das IOdev des virtuellen Device des vtc irrelevant.

Zitatmsgload ist jetzt aber von durschnittlich 6% auf 0% gesunken. iodev ist sowohl bei vtc, als auch vd, hmlan.

hm - gesendet wird aber noch?

frank · 05 Mai 2014, 11:54:22

jetzt wird es mir langsam unheimlich.

ich habe nun cul, hmusb und hmlan auf alles loggen lassen. siehe da, der cul dachte wohl: wenn sich 2 streiten übernehme ich einfach mal das senden.

ein "get hminfo param -d IODev" ergibt:

Code Auswählen

param done: 
 param list 
    entity              	: IODev                	| 
    CUL_HM_HM_LC_Sw1PBU_FM_266E75	: hmlan1 
    CUL_HM_ID__00012D   	: cul868 
    DimPBU01            	: hmlan1 
    DimUP01             	: hmlan1 
    Fenster.Bad         	: hmlan1 
    SwitchES01          	: hmlan1 
    SwitchPBU01         	: cul868 
    TCControler.Bad     	: hmusb1 
    TCControler.Kueche  	: hmusb1 
    TCControler.SZ      	: hmusb1 
    TCControler.WZ      	: hmusb1 
    Thermostat.Bad      	: hmlan1 
    Thermostat.Kueche   	: hmlan1 
    Thermostat.SZ       	: hmlan1 
    Thermostat.WZ       	: hmlan1 
    Tuer.SZ             	: hmlan1 
    Tuer.WZ.Terrasse    	: hmlan1 
    Ventil.AZ.Nord      	: hmlan1 
    Ventil.Bad          	: hmlan1 
    Ventil.Kueche       	: hmlan1 
    Ventil.SZ           	: hmlan1 
    Ventil.WZ           	: hmlan1 
    VentilControler.AZ.Nord	: hmlan1 
    VentilControler.Bad 	: hmlan1 
    VentilControler.Kueche	: hmlan1 
    VentilControler.SZ  	: hmlan1 
    VentilControler.WZ  	: hmlan1 
    ccu                 	: hmlan1

interessant ist auch das device CUL_HM_ID__00012D. habe ich nie angelegt. hat der nsa jetzt schon homematic trojaner devices?

auf alle fälle stimmt dann aber msgloadest vom hmlan.

gruss frank

martinp876 · 05 Mai 2014, 14:25:58

Zitatich habe nun cul, hmusb und hmlan auf alles loggen lassen. siehe da, der cul dachte wohl: wenn sich 2 streiten übernehme ich einfach mal das senden.

verstehe ich nicht - wer, wann, wie?

Zitat
Zitatinteressant ist auch das device CUL_HM_ID__00012D.

wird angelegt, wenn eine config-message ankommt mit deser ID. Scheint eine korrupte message zu sein.

frank · 05 Mai 2014, 14:35:00

Zitatverstehe ich nicht - wer, wann, wie?

kommunikation vd <=> vtc:

attr vd iodev hmlan
attr vtc iodev hmlan
10_cul_hm mit deinen änderungen

=> cul übernimmt das senden

martinp876 · 05 Mai 2014, 14:40:06

hat sich das "internal IODev" des vd geändert? Sollte entsprechend dem Attribut sein.
was steht im vtc?
war es die valve-message oder eine andere?

frank · 05 Mai 2014, 15:54:42

list vd

Code Auswählen

Internals: 
   DEF        1CE9F5 
   IODev      hmlan1 
   LASTInputDev hmusb1 
   MSGCNT     473 
   NAME       Ventil.WZ 
   NR         297 
   STATE      Vsoll:99 %, Vist:99, Status:99, Operation:onTarget, OpErr:17, Mot:stop, MotErr:ok, Bat:ok, Verr:0 % 
   TYPE       CUL_HM 
   cul868_MSGCNT 157 
   cul868_RAWMSG A0E8482021CE9F5B4B4B40101C6003D::-61.5:cul868 
   cul868_RSSI -61.5 
   cul868_TIME 2014-05-05 14:56:49 
   hmlan1_MSGCNT 158 
   hmlan1_RAWMSG E1CE9F5,0000,03323B45,FF,FFD2,8482021CE9F5B4B4B40101C6003D 
   hmlan1_RSSI -46 
   hmlan1_TIME 2014-05-05 14:56:49 
   hmusb1_MSGCNT 158 
   hmusb1_RAWMSG E1CE9F5,0000,024FE603,FF,FFD1,8482021CE9F5B4B4B40101C6003D 
   hmusb1_RSSI -47 
   hmusb1_TIME 2014-05-05 14:56:50 
   lastMsg    No:84 - t:02 s:1CE9F5 d:B4B4B4 0101C6003D 
   peerList   VentilControler.WZ_Btn1, 
   protLastRcv 2014-05-05 14:56:49 
   rssi_at_cul868 avg:-60.94 min:-67.5 max:-54.5 lst:-61.5 cnt:157 
   rssi_at_hmlan1 avg:-45.87 min:-49 max:-45 lst:-46 cnt:158 
   rssi_at_hmusb1 avg:-48 min:-51 max:-44 lst:-47 cnt:158 
   rssi_hmlan1 avg:-60.1 min:-67 max:-54 lst:-61 cnt:158 
   Readings: 
     2014-04-14 17:01:27   .D-devInfo      010100 
     2014-04-14 17:01:27   .D-stc          58 
     2014-05-05 14:56:49   .protLastRcv    2014-05-05 14:56:49 
     2014-05-04 21:03:12   Activity        alive 
     2014-05-05 14:56:49   CommandAccepted yes 
     2014-04-14 17:01:27   D-firmware      2.0 
     2014-04-14 17:01:27   D-serialNr      JEQ0237233 
     2014-04-14 17:01:06   PairedTo        0x123ABC 
     2014-04-14 17:01:06   R-pairCentral   0x123ABC 
     2014-04-10 16:30:01   R-valveErrorPos 0 % 
     2014-04-10 16:30:01   R-valveOffset   0 % 
     2014-04-14 17:01:06   RegL_00:        02:01 0A:12 0B:3A 0C:BC 00:00 
     2014-04-14 17:01:07   RegL_05:        09:00 0A:00 00:00 
     2014-05-05 13:00:51   ValveDesired    99 % 
     2014-05-05 14:56:49   ValvePosition   99 
     2014-05-05 14:56:49   battery         ok 
     2014-05-05 14:56:49   motor           stop 
     2014-05-05 14:56:49   motorErr        ok 
     2014-05-05 14:56:49   operState       onTarget 
     2014-04-21 18:32:08   operStateErrCnt 17 
     2014-05-04 21:03:12   peerList        VentilControler.WZ_Btn1, 
     2014-04-14 16:56:24   powerOn         - 
     2014-05-05 14:56:49   recentStateType ack 
     2014-05-03 12:48:57   rssi_HMLAN1     -46 
     2014-05-03 12:48:57   rssi_at_HMLAN1  -45 
     2014-05-05 14:56:49   rssi_at_cul868  -61.5 
     2014-05-05 14:56:49   rssi_at_hmlan1  -46 
     2014-05-05 14:56:49   rssi_at_hmusb1  -47 
     2014-05-05 14:56:49   rssi_hmlan1     -61 
     2014-05-03 20:17:30   rssi_hmusb1     -45 
     2014-05-05 14:56:49   state           99 
   Helper: 
     mId        003A 
     oldDes     99 
     rxType     12 
     Bm: 
       Cul_hm_set: 
         cnt        4 
         dmx        0 
         mAr        HASH(0x12827f8); Ventil.WZ; ? 
         max        16 
         tot        59 
     Io: 
       newChn     +1CE9F5,00,01,1E 
       nextSend   1399294610.08807 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
     Rssi: 
       At_cul868: 
         avg        -60.9490445859872 
         cnt        157 
         lst        -61.5 
         max        -54.5 
         min        -67.5 
       At_hmlan1: 
         avg        -45.873417721519 
         cnt        158 
         lst        -46 
         max        -45 
         min        -49 
       At_hmusb1: 
         avg        -48.006329113924 
         cnt        158 
         lst        -47 
         max        -44 
         min        -51 
       Hmlan1: 
         avg        -60.1012658227848 
         cnt        158 
         lst        -61 
         max        -54 
         min        -67 
Attributes: 
   .devInfo   010100 
   .stc       58 
   IODev      hmlan1 
   actCycle   028:00 
   actStatus  alive 
   alias      40. Ventil 
   autoReadReg 5_readMissing 
   event-on-change-reading .* 
   expert     2_full 
   firmware   2.0 
   group      Heizung.WZ 
   model      HM-CC-VD 
   peerIDs    00000000,B4B4B401, 
   room       98_Ventile 
   rssiLog    1 
   serialNr   JEQ0237233 
   stateFormat Vsoll:ValveDesired, Vist:ValvePosition, Status:state, Operation:operState, OpErr:operStateErrCnt, Mot:motor, MotErr:motorErr, Bat:battery, Verr:R-valveErrorPos 
   subType    thermostat 
   webCmd     getConfig

list vtc device

Code Auswählen

Internals: 
   DEF        B4B4B4 
   IODev      hmlan1 
   LASTInputDev hmusb1 
   MSGCNT     322 
   NAME       VentilControler.WZ 
   NR         298 
   STATE      CMDs_done 
   TYPE       CUL_HM 
   channel_01 VentilControler.WZ_Btn1 
   hmlan1_MSGCNT 161 
   hmlan1_RAWMSG EB4B4B4,0000,03391DBA,FF,FFDF,87A258B4B4B41CE9F500FD 
   hmlan1_RSSI -33 
   hmlan1_TIME 2014-05-05 15:04:21 
   hmusb1_MSGCNT 161 
   hmusb1_RAWMSG EB4B4B4,0000,0256C831,FF,FFE5,87A258B4B4B41CE9F500FD 
   hmusb1_RSSI -27 
   hmusb1_TIME 2014-05-05 15:04:21 
   lastMsg    No:87 - t:58 s:B4B4B4 d:1CE9F5 00FD 
   protLastRcv 2014-05-05 15:04:21 
   rssi_at_hmlan1 avg:-32.8 min:-33 max:-32 lst:-33 cnt:161 
   rssi_at_hmusb1 avg:-26.16 min:-27 max:-25 lst:-27 cnt:161 
   Readings: 
     2014-05-05 15:04:21   .protLastRcv    2014-05-05 15:04:21 
     2014-05-04 21:01:06   state           CMDs_done 
   Helper: 
     Io: 
       newChn     +B4B4B4,00,01,1E 
       nextSend   1399295061.16035 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       dev        1 
       vrt        1 
     Rssi: 
       At_hmlan1: 
         avg        -32.8074534161491 
         cnt        161 
         lst        -33 
         max        -32 
         min        -33 
       At_hmusb1: 
         avg        -26.1614906832298 
         cnt        161 
         lst        -27 
         max        -25 
         min        -27 
Attributes: 
   IODev      hmlan1 
   autoReadReg 5_readMissing 
   event-on-update-reading state 
   expert     2_full 
   group      Heizung.WZ 
   model      virtual_1 
   msgRepeat  0 
   room       10_WZ 
   subType    virtual 
   webCmd     press short:press long

list vtc channel01

Code Auswählen

Internals: 
   .triggerUsed 1 
   DEF        B4B4B401 
   NAME       VentilControler.WZ_Btn1 
   NR         299 
   STATE      Vsoll:99 %, Status:ValveAdjust:99 %, Kommunikation:ok, ErrCtr:40, Modus:msgReduce:2 
   TYPE       CUL_HM 
   chanNo     01 
   device     VentilControler.WZ 
   peerList   Ventil.WZ, 
   .userreadings: 
     Msgreduce: 
       TIME       2014-05-05 15:12:00 
       modifier   none 
       perlCode   {AttrVal($name,"param","???")} 
       t          1399295520.40723 
       trigger 
       value      msgReduce:2 
   Readings: 
     2014-05-05 15:12:00   .next           138;1399295674.14687 
     2014-05-05 09:00:36   errorCtr        40 
     2014-05-05 09:03:33   errorState      ok 
     2014-05-05 15:12:00   msgReduce       msgReduce:2 
     2014-05-04 21:03:14   peerList        Ventil.WZ, 
     2014-05-05 13:00:51   state           ValveAdjust:99 % 
     2014-05-05 09:03:33   valveCtrl       ok 
     2014-05-05 09:03:33   valveCtrlRam    ok 
     2014-05-05 13:00:51   valvePosTC      99 % 
   Helper: 
     fkt        vdCtrl 
     virtTC     00 
     Bm: 
       Cul_hm_set: 
         cnt        26 
         dmx        0 
         mAr        HASH(0x1282908); VentilControler.WZ_Btn1; valvePos; 5 
         max        375 
         tot        4286 
     Role: 
       chn        1 
       vrt        1 
     Vd: 
       IODev      cul868 
       STATE      CMDs_processing... 
       ackT       2014-05-05 15:11:50 
       cmd        A258B4B4B41CE9F5 
       id         1CE9F5 
       idh        3613860 
       idl        46080 
       miss       0 
       msgCnt     138 
       msgRed     2 
       msgSent    0 
       next       1399295674.14687 
       nextM      1399295674.14687 
       protSnd    162 last_at:2014-05-05 15:11:50 
       protState  CMDs_processing... 
       typ        1 
       val        FD 
       vin        99 
       Readings: 
         2014-05-05 15:11:50   state           CMDs_processing... 
       Helper: 
         Prt: 
           sProc      1 
           Rspwait: 
             cmd        As0B8AA258B4B4B41CE9F500FD 
             mNo        8A 
             reSent     1 
         Role: 
Attributes: 
   alias      30. Controler 
   event-on-change-reading .* 
   event-on-update-reading state,valvePosTC 
   expert     1_on 
   group      Heizung.WZ 
   model      virtual_1 
   param      msgReduce:2 
   peerIDs    1CE9F501, 
   room       98_Ventile 
   stateFormat Vsoll:valvePosTC, Status:state, Kommunikation:valveCtrl, ErrCtr:errorCtr, Modus:msgReduce 
   userReadings msgReduce {AttrVal($name,"param","???")} 
   webCmd     press short:press long

insgesamt sind 5 vd betroffen.

der cul sendet alle valve-messages.
ein getconfig auf einen vd wurde vom hmlan gesendet

beobachtung:
im list vom vd (siehe oben) steht unter internals lastIODev=hmusb. anschliessend bin ich auf detailseite des vd, um das getconfig zu senden. hier stand nun aber unter lastIODev=cul.
ich habe bisher lastIODev so interpretiert, dass dort das io angezeigt wird, welches vor dem aktuell unter attr IODev eingetragenen io eingetragen war. ist dem nicht so?

gruss frank

martinp876 · 05 Mai 2014, 20:03:49

Beim Senden geben ich an, wer etwas senden will (oder an wen). Der Zentrale dispatcher schaut in IODev nach, welches IOdevice dem Anforderer zugeordnet ist und sendet über diesen.
Internals IODev könnte geändert werden, das würdest du aber sehen - in Internals.
Ich hoffe, es wird nichts anderes gemacht - es gibt noch ersatzschaltungen und sendepools... die werdena ber hoffentlich nicht genutzt.

LASTInputDev wird auch vom dispatcher gefüllt - und zeigt an, wer zuletzt an das entsprechende Device gesendet hat. So du mehrere IOs hast, welche die gleiche message auffangen werden allen an CUL_HM weiter gegeben - die Erste wird ausgewertet, die anderen als duplicate verworfen. Aber dennoch wird der letzte als LASTInputDev gesichert. Es hat also nur wenig Aussagekraft - was auch immer du hier herauslesen willst.

Ein lastIODev finde ich garnicht. sollte wohl LASTInputDev heissen.
Beachte, das der Name stimmt - das ist ein InputDevice - hat nichts mit output zu tun!

der Name IODev hingegen ist nicht korrekt - es ist nicht IO sondern eigentlich ein OutputDevice. Input wird hier (zumindest bei HM) nicht festgelegt.
Das Attribut IODev wird quasi in das Internal IODev eingetragen. Mit LASTInputDev hat es nichts zu tun.

Grund ist, dass das Attribut in fhem.cfg gesichert wird. Außerdem könnte man hier auch Sendepools definieren (z.B. eine CCU eintragen, dann darf die CCU ein IODev bestimmen... dynamisch). Das läst Raum für features

klärt dies das Verhalten? Oder wird wirklich von der CUL gesendet?

Gruss Martin

frank · 05 Mai 2014, 20:18:40

ZitatOder wird wirklich von der CUL gesendet?

ja!
die cul sendet alle valvepos masseges an die ventile.

martinp876 · 06 Mai 2014, 12:45:26

probiere CUL_HM 5763

frank · 06 Mai 2014, 14:34:39

Zitat von: martinp876 am 06 Mai 2014, 12:45:26
probiere CUL_HM 5763

~~funktioniert sehr gut!~~

mit
attr vd IODev hmlan
attr vtc IODev cul
wird nun alles über hmlan gesendet. valvepos und getconfig.

hat die einstellung am vtc nun gar keinen einfluss mehr? oder gibt es spezial fälle?

jetzt muss die lösung noch für den virtuellen vd eingebaut werden.

edit:
ein eingeschlafenes ventil, wird im log von B4B4B4 angesteuert, lässt sich nich mehr durch einfaches drücken des anlerntasters reannimieren. im augenblick macht es den anschein, als ob die ventile nach einem getconfig probleme mit dem timing bekommen. ich schau mal weiter.
ausserdem fehlen die cul_parse einträge im log. der hat verbose4.
das attr vtc msgrepeat=0 macht auch nicht mehr was es soll.

gruss frank

martinp876 · 06 Mai 2014, 18:04:24

das output-device wird immer von der Destination genommen. Bei virtuellen stimmt dies evtl noch nicht überall - werde ich aber behenen, wenn ich es entdecke.
Im Falle eines Broadcast wird natürlich das Source-device genommen.

von deinem VD sehe ich noch nicht einmal eine config-message. Falls su also anlernen gedrückt hast, hatte es keinen effekt.

Gruss Martin

frank · 06 Mai 2014, 18:25:39

Zitatvon deinem VD sehe ich noch nicht einmal eine config-message.

bei kurzem drücken des configtasters am vd, wird dieser auch nur für ca 15 min in de wachzustand versetzt. dann können vd und vtc normalerweise wieder kontakt aufnemen. nach kurzer zeit bewegt sich der vd auch aus der errposition, schläft aber gleich wieder ein.
2 weitere vd, denen ich ein getconfig gesendet habe, sind kurz darauf auch eingeschlafen. von 5 stück läuft nur noch einer. der hatte nach dem getconfig kurz probleme, hat sich aber gefangen.

ich warte noch, ob die 2 sich selber fangen. dann muss ich wieder die alte version einspielen.

gruss frank