TC emulieren

[martinp876]

Hi Frank,

ok - bau ich ein - gerade im test, mit 2 timern wie von dir vorgeschlagem

Gruss Martin

[frank]

hallo martin,

kann es kaum erwarten!

wo du schon mal dabei bist, könntest du gleich noch mal ein neues feature einbauen.

meines wissens nach weiss fhem bisher nicht, wann und ob ein vd auf "valveErrorPos" steht. in der prüfungssequenz könnte man doch einen zähler einbauen, der bei jeder fehlenden antwort um 1 erhöht und bei erfolgter antwort auf 0 zurückgesetzt wird. sobald der zähler >=6 ist, müsste man das reading valvePosition=valveErrorPos setzen und im state eventuell den hinweis "15% ErrorPosition" anzeigen.
ein neues reading "missingCommunication" mit dem inhalt des zählers könnte auch gute hinweise auf die qualität der kommunikation geben.

diese routine wäre auch beim realen tc sinnvoll.

desweiteren wäre beim parentdevice des virtuellen tc der befehl "set clear [readings|msgEvents|register|rssi]" hilfreich, sowie die anzeige der rssi-werte. sollte einmal für jeden vd ein eigener channel existieren, müssten die protokoll- und rssidaten eventuel in den channelbereich verlegt werden.

nun noch zwei "merkwürdigkeiten" die mir in der 10_CUL_HM.pm aufgefallen sind.

1. das semikolon hinter der schliessenden if-klammer (zeile 3187):

Code Auswählen Erweitern

      if (!$hash->{helper}{virtTC}){
        $hash->{helper}{vd}{next} = gettimeofday()
              if (!defined $hash->{helper}{vd}{next});
        $hash->{helper}{virtTC} = "03";
        CUL_HM_valvePosUpdt("valvePos:$dst$chn");
      };
      $hash->{helper}{virtTC} = "03";
      $state = "ValveAdjust:$vp %";


2. die variablendefinition ausserhalb der subdefinition (zeile 3505):

Code Auswählen Erweitern

my $updtValveCnt = 0;
sub CUL_HM_valvePosUpdt(@) {#update valve position periodically to please valve


gruss frank

[martinp876]

hallo martin,

V 4705 ist verfügbar

meines wissens nach weiss fhem bisher nicht, wann und ob ein vd auf "valveErrorPos" steht.

bekommen wir auch nicht gesagt... Leider meldet der vd das nicht.

der bei jeder fehlenden antwort um 1 erhöht und bei erfolgter antwort auf 0 zurückgesetzt wird.

hm

sobald der zähler >=6 ist, müsste man das reading valvePosition=valveErrorPos setzen und im state eventuell den hinweis "15% ErrorPosition" anzeigen.

15% ist programmierbar - könnte ein anderer Wert sein.
das ist eine Mutmassung. Sicher ist nur, das FHEM nichts gehört hat. Sollte gleich sein für virtuellen und echten TC.

ein neues reading "missingCommunication" mit dem inhalt des zählers könnte auch gute hinweise auf die qualität der kommunikation geben.

du könntest den actCycle auf 15 oder 20min setzen. der Prüft so etwas. Dann bekommst du dead - was in gewisser weise stimmt.

diese routine wäre auch beim realen tc sinnvoll.

wenn, dann ja.
Allgemein habe ich etwas Probleme damit. Es müsste dann eigentlich die gesamte kommunikation überwacht werden, jeder sender mit jedem Empfänger... das ist einiges..

desweiteren wäre beim parentdevice des virtuellen tc der befehl "set clear [readings|msgEvents|register|rssi]" hilfreich

ok

sowie die anzeige der rssi-werte. sollte einmal für jeden vd ein eigener channel existieren, müssten die protokoll- und rssidaten eventuel in den channelbereich verlegt werden.

wieso? Kann ein channel andere werte empfangen als sein device? ein channel sendet und empfängt nicht,hat auch keinen RSSI wert.
RSSI von virtuellen Devices... sind die des IODev... aber gut

Gruss Martin

[martinp876]

da der controller anzeigen muss ob sein Sklave noch werkelt muss hier eine Anzeigen her... da hast du recht.

ich habe jetzt:
anzahl peers auf 1 beschränkt. beim setzen der valvePos wird es geprüft - das kommando ggf nicht akzeptiert.
der vtc bekommt ein Reading
valveCtrl [init|ok|lost]

lost habe ich - nach de

ist das ok? V4707 sollte dies berücksichtigen.

Gruss Martin

[frank]

hallo martin,

hier überschlagen sich ja die ereignisse. jetzt komm ich gleich nicht mehr hinterher!

erst mal muss ich mit dir auf deine v4705 "virtuell anstossen". auch auf wkarl, der den entscheidenen hinweis gegeben hat. nicht zu vergessen die jungs von homegear mit ihrer unglaublichen eventTime-funktion.
ich habe ja den verdacht, dass sie die original firmware von vd und tc haben. bei gelegenheit wollte ich da noch mal anklingeln, ob da eventuell diesbezüglich was abzustauben ist. da wir hier im forum mittlerweile eigene firmware bauen, die deutlich besser ist als das original, könnte man auf einfache weise das original "aufpimpen". alles in allem hervorragende arbeit.

seit einer guten stunde bügelt der vtc mit v4705 alle kommunikationsprobleme augenblicklich weg. ich habe noch mal je einen delay-logger in die funktionen eingebaut, um genau zu testen. scheint alles so zu funktionieren, wie erhofft!
es scheint sogar so zu sein, dass der 10s-timer bereits diverse verzögerungen einsammelt, die dann später beim eventTime-timer keine auswirkungen mehr haben können. insgesamt also wesentlich stabiler! warum auch immer. sind timer so anfällig? dann sollten wir überlegen, den 10s-timer vielleicht noch deutlich zu erhöhen.

so jetzt zum neuen feature:

du hast natürlich recht, dass die info von 6 fehlgeschlagenen kommunikationen keine "gewissheit" über den tatsächlichen zustand des vd gibt.
doch bei einem virtuellen tc sollte diese ungewissheit vernachlässigbar sein, da der user zwingend für guten funkkontakt sorgen muss, um überhaupt ein nutzbares system zu bekommen.
beim realen tc sieht das etwas anders aus, da hier der tc in der regel besseren funkkontakt mit dem vd haben wird, als die zentrale mit beiden einzeln. auch wird der normale user hier nicht nach funkproblemen zwischen zentrale und device ausschau halten, solange die heizung die bude warm hält.

mit dem reading des zählerstandes wollte ich eigentlich die qualität der kommunikation beobachten. wenn alles "normal" bei mir läuft, gibt es ab und an nur ein unbeantwortetes climateEvent am stück, 2 selten, 3 fast nie, 4 und 5 erwarte ich eigentlich nicht mehr. es sei denn, meine fritzbox hat keine puste mehr. 6 sollten der vergangenheit angehören.

valveCtrl [init|ok|lost]

lost habe ich - nach de

wenn du noch ein "warning" spendierst, vielleicht 4, finde ich das auch gut.

also auf zu v4707,
gruss frank

[frank]

hallo martin,

Code Auswählen Erweitern

    CUL_HM_UpdtReadSingle($hash,"valveCtrl","lost",1)
          if(   $hash->{helper}{vd}{miss} > 6
             && ReadingsVal($hash->{NAME},"valveCtrl","") ne "lost");


lost ist eigentlich schon bei 6 fehlversuchen. also ">=6".


ansonsten kannst du das attr msgRepeat default auf 0 setzen und eventuell sperren. macht in dieser anwendung keinen sinn und reduziert die funklast.

gruss frank

[martinp876]

Hi Frank

hier überschlagen sich ja die ereignisse. jetzt komm ich gleich nicht mehr hinterher!

du hast mich ja ganz schön getrieben da muss ich auch einmal vorwärts kommen.

auch auf wkarl, der den entscheidenen hinweis gegeben hat. nicht zu vergessen die jungs von homegear mit ihrer unglaublichen eventTime-funktion.
ich habe ja den verdacht, dass sie die original firmware von vd und tc haben.

hm . ich wäre auf diese Formel nicht gekommen...

ob da eventuell diesbezüglich was abzustauben ist....

ich habe leider nichts (ausser Fragen...)

ich habe noch mal je einen delay-logger in die funktionen eingebaut, um genau zu testen

macht sinn - aber nur zum testen...

10s-timer bereits diverse verzögerungen einsammelt.

denkbar - das ist entkoppelt vom senden und readings setzen,...

sind timer so anfällig?

wie mans nimmt - sehr. Konzeptbedingt

dann sollten wir überlegen, den 10s-timer vielleicht noch deutlich zu erhöhen.

an der dauer liegt es wohl nicht...

wenn du noch ein "warning" spendierst, vielleicht 4, finde ich das auch gut

wie meinst du das? Bei fehler- count= 4 ein warning?
hm kann man machen. oder bei 1?

lost ist eigentlich schon bei 6 fehlversuchen. also ">=6".

kann ich machen. Ist 6 irgendwie vorgegeben?
Gruss Martin

[frank]

hallo martin,

0,1,2,3 => ok
4,5 => warning
6,7,.... => lost

Ist 6 irgendwie vorgegeben?

When for whatever reason a master device (e. g. a HM-CC-TC) is not transmitting cyclic packets at all (maybe because the battery is empty), the destination (or slave) device (e. g. a HM-CC-VD) wakes up for six more duty cycles. With each duty cycle the device stays 500ms longer in Rx mode, so the durations in Rx mode for the six cycles are:

    250 ms
    750 ms
    1250 ms
    1750 ms
    2250 ms
    2750 ms

gruss frank

[martinp876]

Hallo Frank,

Es scheint mir übrigens, dass er nach (sehr) langer wartezeit auf dauer-an ist.

Das mit der "4" verstehe ich nicht - ist doch sehr zufällig gewählt. Entweder ganz oder garnicht...?
ich habe jetzt
0 => ok
1,2,3,4,5 => miss_1,miss_2,...
6,7,.... => lost
wenn es Probleme gibt sollte man sie alle sehen können, meine ich.
Gruss Martin

[frank]

hallo martin,

Es scheint mir übrigens, dass er nach (sehr) langer wartezeit auf dauer-an ist.

wenn du meinst, dass der vd, nachdem er die kommunikation eingestellt hat (lost), nach weiteren ca 75 min auf "dauer-an" geht, dann hast du gut beobachtet. wenn der tc in seinem üblichen trott weiter funkt, können die beiden spätestens nach 75 min wieder normal kommunizieren.

Das mit der "4" verstehe ich nicht - ist doch sehr zufällig gewählt.

richtig. ich dachte du wolltest "sparen"!

Entweder ganz oder garnicht...?

ein mann, ein wort!

ich habe jetzt
0 => ok
1,2,3,4,5 => miss_1,miss_2,...
6,7,.... => lost
wenn es Probleme gibt sollte man sie alle sehen können, meine ich.

perfekt!
war eigentlich von anfang an mein plan.


ich habe jetzt mal eine in meinem haus installierte vd/tc-kombi entpeert und eine notify/vtc-kombi zwischen geschaltet. hat wohl hervorragend funktioniert. der test-vd funktionierte mit eigenem vtc weiterhin sehr gut.

mein eigentliches ziel ist eine heizungsregelung mit "variablem referenzraum". der raum mit der aktuell grössten heizanforderung beeinflusst über Tsoll/Tist die vorlauftemperatur. das macht nur sinn, wenn im aktuellen referenzraum alle heizkörperventile auf 100% sind. wechselt der referenzraum, müssen die ventile wieder auf automatik gehen, also vom entsprechenden tc gesteurt werden.
meine bisherige realisierung über das register mdTempValve im tc funktioniert leider nur vom prinzip, ist in der realität aber eigentlich nicht zu gebrauchen. nun der ansatz über das vtc.

der reale tc ohne gepeerten vd sendet wohl weiterhin brav die entsprechenden actuator-sollwerte. es gibt nur das problem, dass der tc stündlich meckert (beep) und im display das antennensymbol binkt mit angezeigtem "v". ich muss dich wohl schon mal langsam darauf einstimmen, einen virtuellen vd zu entwerfen, damit meine frau keinen nervenzusammenbruch vom beepen bekommt!

gruss frank

[martinp876]

perfekt!
war eigentlich von anfang an mein plan.

irgendwann hast du mich so weit...
Die readings sollten begrenzt sein, hoffe ich...

das File habe ich gerade eingecheckt. V4711

funktioniert ein virtuellen VD nicht? dachte das hatten wir schon - aber muss noch einmal probieren...

[frank]

hallo martin,

ich habe jetzt 4 vd mit 4 vtc gepeert. das funktioniert soweit sehr gut.

dann habe ich zusätzlich 4 vvd definiert und mit den entsprechenden tc gepeert. als beispiel folgenden log:

Code Auswählen Erweitern

2014.01.24 00:30:48.656 0: HMLAN_Parse: HMLAN1 R:E1936FF   stat:0000 t:44B36A31 d:FF r:FFB6     m:9B A258 1936FF D3D3D3 0083
2014.01.24 00:30:48.892 0: HMLAN_Send:  HMLAN1 S:SC17110F9 stat:  00 t:00000000 d:01 r:C17110F9 m:9B 8002 D3D3D3 1936FF 0101660000
2014.01.24 00:30:49.658 0: HMLAN_Parse: HMLAN1 R:RC17110F9 stat:0002 t:00000000 d:FF r:7FFF     m:9B 8002 D3D3D3 1936FF 0101660000


das sieht ja erst einmal gut aus. der reale tc sendet das climateEvent und mein virtueller vd die antwort. dem tc scheint das nicht zu genügen. das antennensymbol blinkt, ein kleines v ist sichtbar und im tc-menü unter VST (valvestatus) sieht man eine 1, für einen gepeerten vd, aber kein wert, sondern "-- -- %".

bei einem tc ist manchmal ruhe, dann steht auch ein wert im VST-menü.

wahrscheinlich gibt es hier wieder ein timing problem. die antwort kommt eventuell zu spät. bei homegear hatte ich gelesen, dass der tc exakt 20s nach dem weatherEvent wach wird, um dann gegebenenfalls anfragen abzuarbeiten.

ansonsten ist mir aufgefallen, dass der reale vd mit "8202" antwortet, unser vvd aber mit "8002". testweise hatte ich das mal umgestellt, aber keine besserung bemerkt.

wenn ich den obigen log betrachte, gehe ich mal davon aus, dass der hmlan ein sendemodul und ein empfangsmodul besitzt. das was er selber sendet, empfängt er 766ms später. somit kann man eventuell annehmen, dass der tc sein ClimateEvent ebenfalls 766ms vor dem empfang am hmlan sendet. das wiederum würde dann bedeuten, dass unsere antwort auf den tc 1002ms später erfolgt. wahrscheinlich viel zu spät, wenn man bedenkt, dass das fenster beim vd gerade mal 250ms hat.
alles nur spekulationen, aber fakt ist, der tc kann mit unserer antwort nichts anfangen.

kann man die antworten irgendwie früher senden? einen 20sek-timer einzubauen und auf verdacht die antwort "rauszuhauen", macht wohl auch keinen sinn.

was kann ich tun, oder was mache ich falsch?

gruss frank

[martinp876]

Hi Frank,

bei einem tc ist manchmal ruhe, dann steht auch ein wert im VST-menü.
könnte sein, dass der TC den Inhalt der message prüft...

wahrscheinlich gibt es hier wieder ein timing problem. die antwort kommt eventuell zu spät. bei homegear hatte ich gelesen, dass der tc exakt 20s nach dem weatherEvent wach wird...

das timing gibt der TC vor. Wenn wir ein problem haben, dann dass dein Antwort nicht 250ms nach dem request kommt. Viel rechnen muss man hier definitv nicht, der Teil ist einfach

...der reale vd mit "8202" antwortet, unser vvd aber mit "8002". testweise hatte ich das mal umgestellt, aber keine besserung bemerkt

.
habe ich gesehen - hätte mich gewundert. das ist ein messageFlag - irgendetwas mit GruppenType oder so... Gut dass du es getestet hast.

wenn ich den obigen log betrachte, gehe ich mal davon aus, dass der hmlan ein sendemodul und ein empfangsmodul besitzt. das was er selber sendet, empfängt er 766ms später.

nein. HMLAN informiert seine Zentrale, dass eine message erfolgreich gesendet wurde. Da es eine message ohne AntwortRequest war ist es für ihn erledigt. Status 0002

somit kann man eventuell annehmen, dass der tc sein ClimateEvent ebenfalls 766ms vor dem empfang am hmlan sendet. das wiederum würde dann bedeuten, dass unsere antwort auf den tc 1002ms später erfolgt. wahrscheinlich viel zu spät, wenn man bedenkt, dass das fenster beim vd gerade mal 250ms hat.

ein... wir unterhalten uns erfolgreich mit dem TC wenn er aufwacht. Timing ist: 100-250ms nach dem empfang senden. Achtung: Acks können schneller gesendet werden. Der VD sendet einen ACKinfo

alles nur spekulationen, aber fakt ist, der tc kann mit unserer antwort nichts anfangen.

kann man die antworten irgendwie früher senden? einen 20sek-timer einzubauen und auf verdacht die antwort "rauszuhauen", macht wohl auch keinen sinn.

macht keinen sinn - der VD sendet exact nach dem TC. Wenn du es genau haben willst solltest du die Zeitstempel des HMLAN vergleichen, wenn realer VD mit realem TC arbeitet - einfach die t:... von einander abziehen. Das timing ist sehr präzise, da aus FW generiert - FHEM ist deutlich schlechter. Habe einmal eine alte Tabelle eingefügt - der VD antwortet wie ein Uhrwert 130ms nach dem TC. In diesem Fall ist die messung von FHEM auch gut, da war nichts los auf dem Rechner

Code Auswählen Erweitern

HMLANTime FHEMTime HMLANTime Delay TC->VD
1 53,338 027BF69E m:5B A258 172A85 150B94 03AE 113,338 41678494
1 53,47 027BF71F m:5B 8202 150B94 172A85 010186101E 113,47 41678623 129
4 0,842 027DE8BF m:5C A258 172A85 150B94 00AE 240,842 41806015
4 0,974 027DE941 m:5C 8202 150B94 172A85 010188001E 240,974 41806145 130
6 58,096 02809D3E m:5D A258 172A85 150B94 00AE 418,096 41983294
6 58,229 02809DC1 m:5D 8202 150B94 172A85 010188001E 418,229 41983425 131
9 40,853 02831919 m:5E A258 172A85 150B94 00AE 580,853 42146073
9 40,984 0283199A m:5E 8202 150B94 172A85 010188001E 580,984 42146202 129
12 9,107 02855C4B m:5F A258 172A85 150B94 00AE 729,107 42294347
12 9,24 02855CCD m:5F 8202 150B94 172A85 010188001E 729,24 42294477 130
14 22,862 028766D8 m:60 A258 172A85 150B94 00AE 862,862 42428120
14 22,993 02876759 m:60 8202 150B94 172A85 010188001E 862,993 42428249 129
17 26,368 028A33C2 m:61 A258 172A85 150B94 00AE 1046,368 42611650
17 26,499 028A3444 m:61 8202 150B94 172A85 010188001E 1046,499 42611780 130
20 15,373 028CC807 m:62 A258 172A85 150B94 00AE 1215,373 42780679
20 15,506 028CC889 m:62 8202 150B94 172A85 010188001E 1215,506 42780809 130
22 49,879 028F23A5 m:63 A258 172A85 150B94 00AE 1369,879 42935205
22 50,011 028F2426 m:63 8202 150B94 172A85 010188001E 1370,011 42935334 129
25 10,132 02914796 m:64 A258 172A85 150B94 00AE 1510,132 43075478
25 10,265 02914818 m:64 8202 150B94 172A85 010188001E 1510,265 43075608 130
27 15,887 029332E1 m:65 A258 172A85 150B94 00AE 1635,887 43201249
27 16,018 02933362 m:65 8202 150B94 172A85 010188001E 1636,018 43201378 129
30 11,142 0295DF90 m:66 A258 172A85 150B94 00AE 1811,142 43376528
30 11,273 0295E011 m:66 8202 150B94 172A85 010188001E 1811,273 43376657 129
32 52,147 02985493 m:67 A258 172A85 150B94 00AE 1972,147 43537555
32 52,28 02985515 m:67 8202 150B94 172A85 010188001E 1972,28 43537685 130
35 18,653 029A90F0 m:68 A258 172A85 150B94 00AE 2118,653 43684080
35 18,784 029A9171 m:68 8202 150B94 172A85 010188001E 2118,784 43684209 129

Ich denke der Schlüssel liegt im Microtiming oder im messageInhalt

[frank]

hallo martin,

Ich denke der Schlüssel liegt im Microtiming oder im messageInhalt

message-inhalt
nach einem tag hin und her testen, kann ich den message-inhalt durch folgende beobachtung ausklammern:

der tc, der bisher wenigsten zeitweise die antworten seines vvd empfangen hat, konnte gestern auf einmal vollends überzeugen. da meine anderen tc im prinzip die gleichen antworten erhalten, aber keinen empfang bestätigt haben, müssen wir uns auf das micro-timing konzentrieren.

micro-timing
für den einsamen erfolg eines einzigen tc, ist wahrscheinlich ein fast leerer batteriesatz in verbindung mit seinen hardwaretoleranzen verantwortlich. er hat den ganzen tag das batteriesymbol angezeigt. seit ich ihm einen neuen satz spendiert habe, empfängt er so viel wie alle anderen. gar nichts!

hat eventuell jemand einen schaltplan vom tc? oder kann bestätigt werden, dass eine geringe versorgungsspannung die taktzeiten des prozessors entscheidend verlängert?

ansonsten habe ich den ganzen tag damit verbracht, die antwort des vvd "vorzuziehen":

1. in der hoffnung ein cul868 könnte schneller reagieren als ein hmlan, habe ich den cul eingebaut, tc fullreset (reset und batterien raus), mit cul gepairt und mit vvd gepeert. IOId von tc und vvd auf cul gesetzt. aber kein erfolg!
ein vvd wird ja nicht gepairt. oder mache ich da etwas falsch?

Code Auswählen Erweitern

2014.01.24 18:24:31.972 4: CUL_Parse: cul868 A 0B 1D A258 1936FF D3D3D3 00001D -59.5
2014.01.24 18:24:31.984 4: RCV L:0B N:1D F:A2 CMD:58 SRC:Thermostat.Bad DST:TCControler.Bad 0000 (ClimateEvent CMD:0x00 ValvePos:0) (,WAKEMEUP,BIDI,RPTEN)
2014.01.24 18:24:32.116 4: CUL_send:  cul868As 0E 1D 8202 D3D3D3 1936FF 0101000000
2014.01.24 18:24:32.136 4: SND L:0E N:1D F:82 CMD:02 SRC:TCControler.Bad DST:Thermostat.Bad 0101000000 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0 RSSI:0) (,WAKEMEUP,RPTEN)

in der aufzeichnung sind es vom empfang bis zum senden 144ms (timestamp).
hier noch mal eine genauere aufzeichnung mit cul (verbose5) und hmlan lauschen.

Code Auswählen Erweitern

2014.01.24 12:37:06.870 5: CUL/RAW: /A0BB9A2581936FFD3D3D300F413
2014.01.24 12:37:06.872 4: CUL_Parse: cul868 A 0B B9 A258 1936FF D3D3D3 00F413 -64.5
2014.01.24 12:37:06.874 5: cul868 dispatch A0BB9A2581936FFD3D3D300F4::-64.5:cul868
2014.01.24 12:37:06.884 4: RCV L:0B N:B9 F:A2 CMD:58 SRC:Thermostat.Bad DST:TCControler.Bad 00F4 (ClimateEvent CMD:0x00 ValvePos:244) (,WAKEMEUP,BIDI,RPTEN)
2014.01.24 12:37:07.011 5: cul868 sending As0EB98202D3D3D31936FF0101BE0000
2014.01.24 12:37:07.014 4: CUL_send:  cul868As 0E B9 8202 D3D3D3 1936FF 0101BE0000
2014.01.24 12:37:07.034 4: SND L:0E N:B9 F:82 CMD:02 SRC:TCControler.Bad DST:Thermostat.Bad 0101BE0000 (ACK_STATUS CHANNEL:0x01 STATUS:0xBE UP:0 DOWN:0 LOWBAT:0 RSSI:0) (,WAKEMEUP,RPTEN)
2014.01.24 12:37:07.538 0: HMLAN_Parse: HMLAN1 R:E1936FF   stat:0000 t:474C74A0 d:FF r:FFB8     m:B9 A258 1936FF D3D3D3 00F4
2014.01.24 12:37:07.550 0: HMLAN_Parse: HMLAN1 R:ED3D3D3   stat:0000 t:474C7551 d:FF r:FFDA     m:B9 8202 D3D3D3 1936FF 0101BE0000


zum vergleich tc/vvd mit hmlan gepaired.

Code Auswählen Erweitern

2014.01.24 23:23:23.774 0: HMLAN_Parse: HMLAN1 R:E1936FF   stat:0000 t:499C3997 d:FF r:FFB8     m:73 A258 1936FF D3D3D3 00EE
2014.01.24 23:23:23.921 0: HMLAN_Send:  HMLAN1 S:SC659B452 stat:  00 t:00000000 d:01 r:C659B452 m:73 8202 D3D3D3 1936FF 0101BA0000
2014.01.24 23:23:25.103 0: HMLAN_Parse: HMLAN1 R:RC659B452 stat:0002 t:00000000 d:FF r:7FFF     m:73 8202 D3D3D3 1936FF 0101BA0000


im folgenden habe ich versucht, die ausführung der antwortmessage in 10_CUL_HM vorzuziehen, richtung dateianfang:

2. im elsif-block (v4711z1581) habe ich "push @ack" vor "push @entities" gesetzt. kein erfolg!

Code Auswählen Erweitern

    elsif($mTp eq "58" && $p =~ m/^(..)(..)/) {# climate event

3. dann habe ich elsif-block (v4711z1581) und if-block (v4711z1543) getauscht

Code Auswählen Erweitern

    if($mTp =~ m/^4/ && @mI > 1) { #Push Button event

4. und zum abschluss habe ich die übergeordnete if/els-struktur (v4711z1542)

Code Auswählen Erweitern

  if(AttrVal($dname, "subType", "none") eq "virtual"){# see if need for answer
vor den if-block (v4711z695) gesetzt.

Code Auswählen Erweitern

  if   ($parse eq "ACK"){# remember - ACKinfo will be passed on

nun wird bei mir "push @ack" in zeile 701 ausgeführt, statt in zeile 1587. kein erfolg!
erstaunlich das noch alles andere läuft.

wie kann ich noch schneller reagieren?
ist ein "push @ack" vielleicht langsamer als die kombi "CUL_HM_PushCmdStack" und "CUL_HM_ProcessCmdStack"?
wo wird der empfang vom hmlan bereitgestellt?
könnte ich an der stelle nicht mal eine "pseudoantwort" im raw-format testweise zurücksenden?

gruss frank

[martinp876]

Hi Frank,

ansonsten habe ich den ganzen tag damit verbracht, die antwort des vvd "vorzuziehen":

achtung - zu früh bringt auch nichts.
Der HMLAN liefert ein Präzises Timing - da sehe ich überhaupt keine Probleme. Hingegen können Probleme an ethernet interface (auch bereits im HMLAN) beginnen.
Ich weiss gerade nicht, ob ich mich wiederhole - egal
Du hast aber zumindest einen Indikator - msgPasreDly teilt dir mit, wie genau wir sind.
Das timing wird beim Senden berücksichtigt.

ein vvd wird ja nicht gepairt. oder mache ich da etwas falsch?

Guter Punkt. Setze das Attribut IODev - mehr ist nicht notwendig.

Das Timing der CUL müsste schlechter sein. USB ist zwar schneller, aber beim HMLAN haben wir den Zeitstempel aus der HW.

Wenn du den HMLAN zum monitoren der CUL laufen lässt kannst du aus den Zeitstempeln des HMLAN (t:.....) den realen Delay der messages ablesen

12:37:07.538 0: HMLAN_Parse: HMLAN1 R:E1936FF   stat:0000 t:474C74A0 d:FF r:FFB8     m:B9 A258 1936FF D3D3D3 00F4
12:37:07.550 0: HMLAN_Parse: HMLAN1 R:ED3D3D3   stat:0000 t:474C7551 d:FF r:FFDA     m:B9 8202 D3D3D3 1936FF 0101BE0000

das sind 177ms - evtl zu spät für ein ACK? Für eine message wäre es in der Toleranz

Wenn du die CUL beschleunigen willst musst du 00_CUL offnen und

Code Auswählen Erweitern

  my $id = (length($fn)>19)?substr($fn,16,6):"";#get HMID destination

  if($id &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;
    }

Code Auswählen Erweitern

  my (undef,$mTy,undef,$id) = unpack 'A8A2A6A6',$fn if(length($fn)>19);

  if($id &&
     $mTy ne "02" &&
     $modules{CUL_HM}{defptr}{$id} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io} &&
     $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}) {
    my $dDly = $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend} - $now;

also die beiden Zeilen einfügen/Ändern

my (undef,$mTy,undef,$id) = unpack 'A8A2A6A6',$fn if(length($fn)>19);
$mTy ne "02" &&


Ich denke, das wird sowieso eingebaut werden

Gruss Martin