TC emulieren

[anierbeck]

Hi Martin,

ok habe jetzt folgendes aufgezeichnet beim schicken des events:

Code Auswählen Erweitern


2014.01.08 20:44:00.261 0: HMLAN_Parse: HM_CFG_USB R:E21BC87   stat:0000 t:0396D652 d:FF r:FFC7     m:7D 8610 21BC87 000000 0AA8DE0F341C
2014.01.08 20:44:08.224 0: HMLAN_Send:  HM_CFG_USB I:K
2014.01.08 20:44:08.393 0: HMLAN_Parse: HM_CFG_USB V:03C3 sNo:JEQ0700361 d:1EBBC9 O:8D0C2D t:03970523 IDcnt:0002
2014.01.08 20:44:33.233 0: HMLAN_Send:  HM_CFG_USB I:K
2014.01.08 20:44:33.254 0: HMLAN_Parse: HM_CFG_USB V:03C3 sNo:JEQ0700361 d:1EBBC9 O:8D0C2D t:039766D3 IDcnt:0002
2014.01.08 20:44:33.732 0: HMLAN_Send:  HM_CFG_USB S:S73628905 stat:  00 t:00000000 d:01 r:73628905 m:58 B112 8D0C2D 21BC87
2014.01.08 20:44:34.278 0: HMLAN_Parse: HM_CFG_USB R:R73628905 stat:0001 t:03976AC3 d:FF r:FFC7     m:58 8002 21BC87 8D0C2D 00
2014.01.08 20:44:34.351 0: HMLAN_Send:  HM_CFG_USB S:+21BC87,00,01,
2014.01.08 20:44:34.353 0: HMLAN_Send:  HM_CFG_USB S:S73628B36 stat:  00 t:00000000 d:01 r:73628B36 m:59 A441 221133 21BC87 0109C8
2014.01.08 20:44:34.694 0: HMLAN_Parse: HM_CFG_USB R:E21BC87   stat:0000 t:03976C59 d:FF r:FFC7     m:59 A002 21BC87 221133 041CC219F1CFF900
2014.01.08 20:44:34.757 0: HMLAN_Send:  HM_CFG_USB S:+21BC87,00,01,
2014.01.08 20:44:34.759 0: HMLAN_Send:  HM_CFG_USB S:S73628CD3 stat:  00 t:00000000 d:01 r:73628CD3 m:59 8002 221133 21BC87 00
2014.01.08 20:44:34.822 0: HMLAN_Parse: HM_CFG_USB R:R73628CD3 stat:0002 t:00000000 d:FF r:7FFF     m:59 8002 221133 21BC87 00
2014.01.08 20:44:34.982 0: HMLAN_Parse: HM_CFG_USB R:E21BC87   stat:0000 t:03976D7F d:FF r:FFC7     m:59 8002 21BC87 221133 80B71E4B41
2014.01.08 20:44:35.238 0: HMLAN_Parse: HM_CFG_USB R:R73628B36 stat:0008 t:00000000 d:FF r:7FFF     m:59 A441 221133 21BC87 0109C8
2014.01.08 20:44:35.240 0: HMLAN_Parse: HM_CFG_USB no ACK from 21BC87
2014.01.08 20:44:35.270 0: HMLAN_Parse: HM_CFG_USB R:R73628B36 stat:0008 t:00000000 d:FF r:7FFF     m:59 A441 221133 21BC87 0109C8
2014.01.08 20:44:35.272 0: HMLAN_Parse: HM_CFG_USB no ACK from 21BC87
2014.01.08 20:44:35.302 0: HMLAN_Parse: HM_CFG_USB R:E21BC87   stat:0000 t:03976E91 d:FF r:FFC7     m:59 A002 21BC87 221133 04074A035D576500
2014.01.08 20:44:35.325 0: HMLAN_Send:  HM_CFG_USB S:S73628F32 stat:  00 t:00000000 d:01 r:73628F32 m:59 8002 221133 21BC87 00
2014.01.08 20:44:36.934 0: HMLAN_Parse: HM_CFG_USB R:R73628F32 stat:0002 t:00000000 d:FF r:7FFF     m:59 8002 221133 21BC87 00


danke und Gruß, Achiim

[martinp876]

Hi Achim,

ich denke, bei deinem TC ist AES aktiviert. Du solltest es abschalten - oder wird es benötig?

Gruss Martin

[anierbeck]

Nun bin ich maximal verwirrt 
Ich versuche mit einem "virtuellen" TC zu erstellen welcher beim "echten" MAX Türkontakt das signal weiter zu geben.
Daher verstehe ich nicht das jetzt AES genutzt wird, bzw. alle anderen steuer-signale wie setDesiredTemp setzen funktionieren.

Danke und Gruß, Achim

[martinp876]

Hi Achim,

nun, dein TC antwortet entsprechend.
Du kannst einmal ein list aller 3 Kanäle senden, dann vergleiche ich es einmal  mit meinen Sample
Setze expert auf 2

Gruss Martin

[anierbeck]

Hi Martin,

nachdem ich in einem Anderen Thread gesehen habe wofür die daten in dem log stehen, gehe ich mal davon aus dass du in folgendem Schnipsel

Code Auswählen Erweitern


2014.01.08 20:44:33.254 0: HMLAN_Parse: HM_CFG_USB V:03C3 sNo:JEQ0700361 d:1EBBC9 O:8D0C2D t:039766D3 IDcnt:0002
2014.01.08 20:44:33.732 0: HMLAN_Send:  HM_CFG_USB S:S73628905 stat:  00 t:00000000 d:01 r:73628905 m:58 B112 8D0C2D 21BC87
2014.01.08 20:44:34.278 0: HMLAN_Parse: HM_CFG_USB R:R73628905 stat:0001 t:03976AC3 d:FF r:FFC7     m:58 8002 21BC87 8D0C2D 00
2014.01.08 20:44:34.351 0: HMLAN_Send:  HM_CFG_USB S:+21BC87,00,01,
2014.01.08 20:44:34.353 0: HMLAN_Send:  HM_CFG_USB S:S73628B36 stat:  00 t:00000000 d:01 r:73628B36 m:59 A441 221133 21BC87 0109C8
2014.01.08 20:44:34.694 0: HMLAN_Parse: HM_CFG_USB R:E21BC87   stat:0000 t:03976C59 d:FF r:FFC7     m:59 A002 21BC87 221133 041CC219F1CFF900
2014.01.08 20:44:34.757 0: HMLAN_Send:  HM_CFG_USB S:+21BC87,00,01,


von Zeile

Code Auswählen Erweitern


2014.01.08 20:44:33.732 0: HMLAN_Send:  HM_CFG_USB S:S73628905 stat:  00 t:00000000 d:01 r:73628905 m:58 B112 8D0C2D 21BC87

bzw.

Code Auswählen Erweitern


2014.01.08 20:44:34.353 0: HMLAN_Send:  HM_CFG_USB S:S73628B36 stat:  00 t:00000000 d:01 r:73628B36 m:59 A441 221133 21BC87 0109C8

ausgehst.
Das device 221133 ist das virtuelle, und 21BC87 ist das tatsächliche Thermostat.

Nun ist es aber so, dass ich ja gar keinen TC habe sondern die Signale von einem Max Fensterkontakt weiter reichen möchte.
Sprich ich habe einen virtuellen TC (221133) welcher das Open event sendet.
Also muss fhem das d:01 setzen, wie kann ich das denn jetzt ausschalten?

Danke und Gruß, Achim

[martinp876]

Hi Achim,

ok, hatte den Kontext verloren.
Du hat einen RT und einen MAX fensterkontakt. Emulieren willst du keinen TC sondern einen HM-fensterkontakt. Mit TC hat es wohl nichts zu tun.
Da es eh über die Zentrale geht kannst du einfach die desired-temp setzen - ok, beim Rückschalten hast du ein Problem mit dem alten Wert.

Ist das jetzt korrekt verstanden?
Dann prüfe, dass der virtuellen SC  (HMId 221133) mit dem RT_WindowRec gepeert ist. Ausserdem sollte der RT (device) das register burstRx gesetzt haben

habe es gerade einmal getestet - wenn ich deinen Aufbau jetzt nicht missverstanden habe  sollte es passen...

Die Antwort deines Device deutet an, dass etwas im RT nicht stimmt - ich vermute, dass du nicht korrekt gepeert hast.
zeige doch einmal eine HMInfo Auswertung
set hm configChech
set hm register -f Flur.Thermostat

Gruss Martin

[anierbeck]

Hi Martin,

genau jetzt richtig verstanden. Sorry das ich die Kürzel durcheinander gebracht habe

Das RT hat burstRx gesetzt, damit stelle ich momentan "manuell" die Temp.

Die Antwort deines Device deutet an, dass etwas im RT nicht stimmt - ich vermute, dass du nicht korrekt gepeert hast.

Dann peer ich die nochmal neu.

zeige doch einmal eine HMInfo Auswertung

und hier schonmal die ausgabe vom set hm register:

Code Auswählen Erweitern


No regs found for:

Flur.Thermostat type:thermostat -
list:peer register         :value
   0:      backOnTime       :10 s
   0:      btnLock          :unlock
   0:      burstRx          :on
   0:      cyclicInfoMsg    :on
   0:      cyclicInfoMsgDis :0
   0:      globalBtnLock    :off
   0:      localResDis      :off
   0:      lowBatLimitRT    :2.1 V
   0:      modusBtnLock     :off
   0:      pairCentral      :0x8D0C2D
                 
                 
Flur.Thermostat_Clima type:thermostat -
list:peer register         :value
   1:      sign             :off
   7:      boostPeriod      :5 min
   7:      boostPos         :80 %
   7:      btnNoBckLight    :off
   7:      dayTemp          :21 C
   7:      daylightSaveTime :on
   7:      decalcTime       :11:00
   7:      decalcWeekday    :Sat
   7:      modePrioManu     :all
   7:      modePrioParty    :all
   7:      nightTemp        :17 C
   7:      noMinMax4Manu    :off
   7:      regAdaptive      :on
   7:      reguExtI         :15
   7:      reguExtP         :30
   7:      reguExtPstart    :30
   7:      reguIntI         :17
   7:      reguIntP         :32
   7:      reguIntPstart    :36
   7:      showInfo         :time
   7:      showWeekday      :off
   7:      tempMax          :30.5 C
   7:      tempMin          :4.5 C
   7:      tempOffset       :0.0K
   7:      valveErrPos      :15 %
   7:      valveMaxPos      :100 %
   7:      valveOffsetRt    :0 %
   7:      winOpnBoost      :off
   7:      winOpnDetFall    :1.4 K
   7:      winOpnMode       :on
   7:      winOpnPeriod     :15 min
   7:      winOpnTemp       :12 C
Temp set: Sat 05:00 17.0 C
Temp set: Sat 06:00 19.0 C
Temp set: Sat 24:00 21.0 C
Temp set: Sun 05:00 17.0 C
Temp set: Sun 06:00 19.0 C
Temp set: Sun 24:00 17.0 C
Temp set: Mon 05:00 17.0 C
Temp set: Mon 06:00 19.0 C
Temp set: Mon 09:00 21.0 C
Temp set: Mon 17:00 19.0 C
Temp set: Mon 24:00 17.0 C
Temp set: Tue 05:00 17.0 C
Temp set: Tue 06:00 19.0 C
Temp set: Tue 09:00 21.0 C
Temp set: Tue 17:00 19.0 C
Temp set: Tue 24:00 17.0 C
Temp set: Wed 05:00 17.0 C
Temp set: Wed 06:00 19.0 C
Temp set: Wed 09:00 21.0 C
Temp set: Wed 17:00 19.0 C
Temp set: Wed 24:00 17.0 C
Temp set: Thu 05:00 17.0 C
Temp set: Thu 06:00 19.0 C
Temp set: Thu 09:00 21.0 C
Temp set: Thu 17:00 19.0 C
Temp set: Thu 24:00 17.0 C
Temp set: Fri 05:00 17.0 C
Temp set: Fri 06:00 19.0 C
Temp set: Fri 09:00 21.0 C
Temp set: Fri 17:00 19.0 C
Temp set: Fri 22:00 21.0 C
Temp set: Fri 24:00 17.0 C
                 
                 
Flur.Thermostat_ClimaTeam type:thermostat -
list:peer register         :value
   1:      sign             :off
                 
                 
Flur.Thermostat_Climate type:thermostat -
list:peer register         :value
   1:      sign             :on
                 
                 
Flur.Thermostat_Weather type:thermostat -
list:peer register         :value
   1:      sign             :off
                 
                 
Flur.Thermostat_WindowRec type:thermostat -
list:peer register         :value
   1:      sign             :on
   7:virtualKitchenDoor winOpnTemp       :12 C
   7:virtualKitchenDoor winOpnTemp       :12 C
                                virtualKitchenDoor
                                sh
CtValLo                         50              50
Flur.Thermostat_remote type:thermostat -
list:peer register         :value
   1:      sign             :off


Danke und Gruß, Achim

[martinp876]

Hallo Achim,

peering scheint ok.
virtualKitchenDoor hat die HMId 22113301 - korrekt?

alles andere beantwortet der RT auch?

seltsam.
winOpnMode sollte auf "off" gestellt werden, wenn der Fensterkontakt verwendet wird - sonst arbeitet der RT ggf intern dagegen. Ist aber nicht das Problem hier.

Kannst du noch einmal ent-peeren und neu peeren? so richtig komme ich nicht weiter.

Gruss Martin

[frank]

hallo martin,

ich konnte endlich die wundervolle implementierung der neuen vd-ansteuerung testen. die berechnung der wachzyclen scheint ja hervorragend zu klapen. nur meine kette aus software und hardware führt die aktionen auf dauer nicht zeitgetreu aus. spätstens nach einer guten stunde wird das wachfenster des vd nicht mehr getroffen.

wenn ich die funktion "sub CUL_HM_valvePosUpdt(@)" richtig verstehe, ruft sich die funktion über den "InternalTimer" immer selber auf, solange "valvePosTC" ungleich "off" ist. verzögerungen im ablauf werden somit ständig aufsummiert. eine synchronisation ist wohl nicht implementiert.

nach den ausführungen von homegear haben wir nur 6 zyclen, mit wachsendem wachfenster (250ms-2750ms), zeit, um wieder einen treffer zu landen. anschließend geht der vd auf valveErrPos und schläft ein. nach ca. 75 min wacht er auf, und wird von fhem wieder am leben gehalten.

vorschlag:
könnte man nicht den letzten erfolgreichen zeitpunkt ermitteln, abspeichern und als neue referenz nehmen? im moment wird dem InternalTimer ein undefeniertes "gettimeofday()" mit auf den weg gegeben. eine aktuelle verzögerung inklusive.
oder man speichert die beiden werte "gettimeofday()+$nextTimer", die man übergibt, und ermittelt beim nächsten durchlauf die aktuelle verzögerung, und kann sie elemimieren.
ich habe mal eine logausgabe mit der aktuellen zycluslänge in die funktion eingebaut. vom letzten erfolgreichen ansteuern bis zum ersten erfolglosen ansteuern ergeben sich bei mir verzögerungen von bis zu 4s, die zum einschlafen des vd führen.

desweiteren habe ich bemerkt, das jede änderung von valvePos ein neustart des messagezählers bedeutet, wodurch weitere probleme auftreten können.
bei einem realen tc läuft der zähler immer durch, ich habe einen vd mal in alufolie gewickelt und die kommunikation von vd und tc geloggt. obwohl der vd während 4 zyclen kein signal erhalten hat, gab es beim anschliessenden zyclus kein problem.
da die zyclen doch sehr unterschiedlich sind, und von der messagenummer abhängig sind, nehme ich an, dass der vd in seiner berechnung von einer kontinuierlichen erhöhung der messagenummer ausgeht. folglich bekommen wir probleme, wenn es während einer verzögerung zu einem messagezählerwechsel kommt. der vd kann das ja nicht vorhersehen.

zum heutigen abschluss noch einmal ein hinweis. ich bin immer noch der meinung, dass das erste climateEvent nach einem valvePos=off einen fehler im payload hat. es fehlt der cmd-anteil. statt 0x80 zb 0x0380.

Code Auswählen Erweitern

2014-01-09_17:16:20 VentilControler.AZ_Btn1 ValveAdjust:stopped
2014-01-09_17:16:34 Ventil.AZ.Nord set_50 %
2014-01-09_17:16:34 Ventil.AZ.Nord ValveDesired: 50 %
2014-01-09_17:16:34 HMLAN1 SND L:0A N:02 F:A2 CMD:58 SRC:VentilControler.AZ DST:Ventil.AZ.Nord [b]80[/b] (ClimateEvent CMD:0x80) (,WAKEMEUP,BIDI,RPTEN)
2014-01-09_17:16:34 VentilControler.AZ_Btn1 ValveAdjust:50 %


bis die tage
frank

[martinp876]

Hallo Frank

verzögerungen im ablauf werden somit ständig aufsummiert. eine synchronisation ist wohl nicht implementiert.

kann man so sehen. Ich erwarte es aber anders herum. Der TC sendet das kommando und legt fest, wann der VD zu erwachen hat - nicht anders herum. So gesehem muss die Zeit ab dem Sendezeitpunkt gerechnet werden.

Ein möglicher Fehler ist natürlich, dass der internal timer einfach zu spät kommt. Dann ist der Zeitpunkt verpasst und fertig.
Probiere einmal den folgenden code mit den Logs. Du brauchst nur einen der beiden - such ihn dir aus...

Code Auswählen Erweitern

sub CUL_HM_valvePosUpdt(@) {#update valve position periodically to please valve
  my($in ) = @_;
  my(undef,$vId) = split(':',$in);
  my $hash = CUL_HM_id2Hash($vId);
  my $vDevId = substr($vId,0,6);
  my $msgCnt = ($hash->{helper}{vd}{msgCnt} + 1)%255;
 
# int32_t result = (((_address << 8) | messageCounter) * 1103515245 + 12345) >> 16;
#                          4e6d = 20077                        12996205 = C64E6D
# return (result & 0xFF) + 480;
  my $idl = $hash->{helper}{vd}{idl}+$msgCnt;
  my $lo = int(($idl*0x4e6d +12345)/0x10000)&0xff;
  my $hi = ($hash->{helper}{vd}{idh}+$idl*198)&0xff;
  my $nextTimer = (($lo+$hi)&0xff)/4 + 120;#original - instable
  my $name = $hash->{NAME};
  my $vp = ReadingsVal($name,"valvePosTC","15 %");
  $vp =~ s/ %//;
  $vp *=2.56;
  my $tn = gettimeofday();
  my $delta = int((gettimeofday() - $hash->{helper}{vd}{next})*1000);
  Log 1,"VD-timing ##### diff:$delta";
  Log 1,"VD-timing Critical ##### diff:$delta" if ($delta >100);
  foreach my $peer (sort(split(',',AttrVal($name,"peerIDs","")))) {
    next if (length($peer) != 8);
    $peer = substr($peer,0,6);
    CUL_HM_PushCmdStack($hash,sprintf("%02XA258%s%s%s%02X",$msgCnt,$vDevId
                                      ,$peer,$hash->{helper}{virtTC},$vp));
  }
  $hash->{helper}{vd}{next} = $tn+$nextTimer;
  $hash->{helper}{vd}{msgCnt} = $msgCnt;
  $hash->{helper}{virtTC} = "00";
  CUL_HM_ProcessCmdStack($hash);
  InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
}

Problem ist, dass FHEM nicht exhtzeitfähing programmiert ist - jedefalls nicht auf dieser Ebene.
Sollte sich dies bewahrheiten kann man das Ganze auch über einen tochterprozess realisieren. Man hängt dann zwar immer noch am OS (das ist auch nicht für echtzeit ausgelegt aber besser) was die Lage verbessern sollte. Eine wirkungsvolle implementierung ist aber dann noch offen.

desweiteren habe ich bemerkt, das jede änderung von valvePos ein neustart des messagezählers bedeutet, wodurch weitere probleme auftreten können.

warum sollte dies ein Problem sein? Der VD hat den Zähler zu nutzen, den der TC vorgibt. Es besteht kein Anspruch auf sequenzilität.

Der Bug beim "off" wird behoben

Lass mich deine tests zum Timing wissen...

Gruss Martin

[anierbeck]

Hallo Martin,

peering scheint ok.
virtualKitchenDoor hat die HMId 22113301 - korrekt?

alles andere beantwortet der RT auch?

Alles Korrekt verstanden

seltsam.
winOpnMode sollte auf "off" gestellt werden, wenn der Fensterkontakt verwendet wird - sonst arbeitet der RT ggf intern dagegen. Ist aber nicht das Problem hier.

Kannst du noch einmal ent-peeren und neu peeren? so richtig komme ich nicht weiter.

Ich habe es jetzt nochmal neu peered, aber das hat mit diesem Thermostat nix gebracht. Mit einem
anderen hat es auf anhieb funktioniert

D.h. ich lasse jetzt meine "manual" Fenstersteuerung für das Flur Thermostat.


Danke und Gruß, Achim

[frank]

hallo martin,

warum sollte dies ein Problem sein? Der VD hat den Zähler zu nutzen, den der TC vorgibt. Es besteht kein Anspruch auf sequenzilität.

solange der vd das climateEvent empfängt, gibt es kein problem. die msgNbr kann beliebig sein. der vd berechnet aus der aktuellen msgNbr die nächste eventTime...

das problem entsteht, wenn der tc eine neue, nicht sequenziell folgende msgNbr übergibt und der vd diese nicht empfängt. woraus berechnet der vd nun die nächste eventTime? nach den beschreibungen von homegear und meinen beobachtungen wacht der vd noch bis zu 5 mal auf. jeweils mit verlängertem wachfenster. da die zeitabstände zwischen diesen 5 wachzuständen völlig unterschiedlich sind und ein realer tc immer sequentielle msgNbrs benutzt, macht es nur sinn, wenn der vd in diesem speziellen fall auch eine sequetielle msgNbr zur berechnung "annimmt".

die timingaufzeichnungen mit der bereitgestellten funktion sind im anhang. die grösste verzögerung beträgt knapp 7,5s.
mit folgender erweiterung läuft mein vd nun seit knapp 3 stunden ohne einzuschlafen! bisher maximal 3 aufeinander folgende climateEvents ohne antwort.

Code Auswählen Erweitern

sub CUL_HM_valvePosUpdt(@) {#update valve position periodically to please valve
  my($in ) = @_;
  my(undef,$vId) = split(':',$in);
  my $hash = CUL_HM_id2Hash($vId);
  my $vDevId = substr($vId,0,6);
  my $msgCnt = ($hash->{helper}{vd}{msgCnt} + 1)%255;
 
# int32_t result = (((_address << 8) | messageCounter) * 1103515245 + 12345) >> 16;
#                          4e6d = 20077                        12996205 = C64E6D
# return (result & 0xFF) + 480;
  my $idl = $hash->{helper}{vd}{idl}+$msgCnt;
  my $lo = int(($idl*0x4e6d +12345)/0x10000)&0xff;
  my $hi = ($hash->{helper}{vd}{idh}+$idl*198)&0xff;
  my $nextTimer = (($lo+$hi)&0xff)/4 + 120;#original - instable
  my $name = $hash->{NAME};
  my $vp = ReadingsVal($name,"valvePosTC","15 %");
  $vp =~ s/ %//;
  $vp *=2.56;
  my $tn = gettimeofday();
  my $delta = int(($tn - $hash->{helper}{vd}{next})*1000);
  Log 1,"VD-timing ##### diff:$delta";
  Log 1,"VD-timing Critical ##### diff:$delta" if ($delta >100);
my $virtDevice = InternalVal($name,"device","");
my $virtDediceState = ReadingsVal($virtDevice,"state","");
Log 1,"VD-timing ##### CtrlState:$virtDediceState";
  foreach my $peer (sort(split(',',AttrVal($name,"peerIDs","")))) {
    next if (length($peer) != 8);
    $peer = substr($peer,0,6);
    CUL_HM_PushCmdStack($hash,sprintf("%02XA258%s%s%s%02X",$msgCnt,$vDevId
                                      ,$peer,$hash->{helper}{virtTC},$vp));
  }
if ($delta > 250) {
$hash->{helper}{vd}{next} += $nextTimer;
}
else {
$hash->{helper}{vd}{next} = $tn+$nextTimer;
}
  $hash->{helper}{vd}{msgCnt} = $msgCnt;
  $hash->{helper}{virtTC} = "00";
  CUL_HM_ProcessCmdStack($hash);
  InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
}


schöner wäre natürlich die nächste eventTime nicht in abhängigkeit von $delta zu berechnen, sondern vom state des virtuellen device (MISSING ACK). dazu fehlt mir aber noch das wissen und der überblick. vielleicht hast du ja eine idee!

noch zwei fragen zur timingaufzeichnung:
1. warum erscheint bei einem climateEvent mit erhaltener antwort trotzdem folgendes

Code Auswählen Erweitern

HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2. es gibt gelungene ereignisse mit 2 antworten, aber einmal mit "dont process":

Code Auswählen Erweitern

2014.01.17 08:41:47.470 1: VD-timing ##### diff:10
2014.01.17 08:41:47.477 0: HMLAN_Send:  HMLAN1 S:S9F260D96 stat:  00 t:00000000 d:01 r:9F260D96 m:38 A258 A1A1A1 1C4E25 0066
2014.01.17 08:41:47.659 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:22673636 d:FF r:FFAE     m:38 8202 1C4E25 A1A1A1 01011E0051
2014.01.17 08:41:47.995 0: HMLAN_Parse: HMLAN1 R:R9F260D96 stat:0008 t:00000000 d:FF r:7FFF     m:38 A258 A1A1A1 1C4E25 0066
2014.01.17 08:41:47.998 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.17 08:41:48.003 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:22673799 d:FF r:FFAE     m:38 8202 1C4E25 A1A1A1 01011E0051
2014.01.17 08:41:48.014 4: CUL_HM Ventil.AZ.Nord dup: dont process

und einanderes mal ohne "dont process".

Code Auswählen Erweitern

2014.01.17 12:15:33.565 1: VD-timing ##### diff:16
2014.01.17 12:15:33.573 0: HMLAN_Send:  HMLAN1 S:S9FE9C386 stat:  00 t:00000000 d:01 r:9FE9C386 m:8C A258 A1A1A1 1C4E25 0066
2014.01.17 12:15:33.759 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:232AF2F0 d:FF r:FFAD     m:8C 8202 1C4E25 A1A1A1 01011E0051
2014.01.17 12:15:34.181 0: HMLAN_Parse: HMLAN1 R:R9FE9C386 stat:0008 t:00000000 d:FF r:7FFF     m:8C A258 A1A1A1 1C4E25 0066
2014.01.17 12:15:34.183 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.17 12:15:34.186 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:232AF453 d:FF r:FFAD     m:8C 8202 1C4E25 A1A1A1 01011E0053


gruss frank

[martinp876]

Hi Frank

das problem entsteht, wenn der tc eine neue, nicht sequenziell folgende msgNbr übergibt und der vd diese nicht empfängt.

nicht empfangen ist ein Problem - eine nicht sequenzielle nummer sollte kein Problem sein. Die Nummer ist immer in der hoheit des TC

woraus berechnet der vd nun die nächste eventTime? nach den beschreibungen von homegear und meinen beobachtungen wacht der vd noch bis zu 5 mal auf.

du bist schon bei der recovery aus dem ersten Fehler - nicht empfangen von messages. Da ist nichts implementiert. Da müsste man noch verbessern - klar.

realer tc immer sequentielle msgNbrs benutzt,

so gesehen - ob das notwendig ist...

wenn der vd in diesem speziellen fall auch eine sequetielle msgNbr zur berechnung "annimmt".

möglich.

nun, der Erfolg gibt dir wohl recht

sollte man also nicht anstelle von

Code Auswählen Erweitern

  if ($delta > 250) {
    $hash->{helper}{vd}{next} += $nextTimer;
  }
  else {
    $hash->{helper}{vd}{next} = $tn+$nextTimer;
  }

einfach

$hash->{helper}{vd}{next} += $nextTimer;

nutzen?

schöner wäre natürlich die nächste eventTime nicht in abhängigkeit von $delta zu berechnen, sondern vom state des virtuellen device (MISSING ACK).

verstehe ich gerade nicht. welches missing-ack - und warum nicht einfach weiterzählen?

HMLAN_Parse: HMLAN1 no ACK from 1C4E25

HMLAN hat eine Nachricht mit ACK-anforderung gesendet und will jetzt ein ach sehen. Es versteht aber nicht, dass die sendeadresse nicht die eigene ist und daher das ACK auch  nicht an seine Adresse kommt. Ein Problem, das keine weiteren Auswirkungen hat, ich aber noch nicht unterdrücken konnte. 

und einanderes mal ohne "dont process".

die message beim ersten Mal war duplicate, beim 2. nicht. Daher ist die eine als wiederholung verworfen worden, die 2. aber nicht.

ich werde einmal testen und dann einchecken

Gruss Martin

[frank]

hallo martin,

in der datei mit den timing-aufzeichnungen gibt es eine sequenz von 36 erfolgreichen kommunikationen am stück (3:44:00-5:13:26). diese aufzeichnungen basieren auf dem eventTime-generator:

Code Auswählen Erweitern

$hash->{helper}{vd}{next} = $tn+$nextTimer;

obwohl hier insgesammt ca. 876ms verzögerungen in die berechnungen eingehen, gibt es keine probleme. sogar grössere verzögerungen von 240ms und 186ms. darum bin ich einfach mal davon ausgegangen, dass sich der vd bei erfolgreichen kommunikationen neu synchronisiert. da das wachfenster angeblich nur 250ms ist, sollte die kommunikation ansonsten irgendwann abgebrochen sein.

wenn wir nun grundsätzlich die verzögerungen mit dem eventTime-generator:

Code Auswählen Erweitern

$hash->{helper}{vd}{next} += $nextTimer;

eleminieren, der vd sich aber resynchronisiert, sind wir irgendwann zu früh dran.

welches missing-ack - und warum nicht einfach weiterzählen?

daher würde ich gerne den ersten eventTime-generator nur in dem fall anwenden, wenn der vd keine antwort gesendet hat. das habe ich mit folgendem code:

Code Auswählen Erweitern

my $virtDevice = InternalVal($name,"device","");
my $virtDeviceState = ReadingsVal($virtDevice,"state","");
Log 1,"VD-timing ##### CtrlState:$virtDeviceState";


auch sehr schön feststellen konnen, aber leider nur von der letzten kommunikation. wir bekommen ein "MISSING ACK" bei fehlender antwort, und ein "CMDs_processing..." wenn eine antwort kam.

"man hängt in der funktion irgendwie, wie zwischen zwei stühlen herum. es gibt informationen von der vorangegangenen kommunikation, die eventuell nicht geklappt hat, und damit auch auswirkungen auf die aktuell anstehende kommunikation hat. ebenso besteht durch eine ermittelte verzögerung der verdacht auf eine erneut misslingende kommunikation, auf die aber nicht mehr reagiert werden kann. aber man muss bereits auf die übernächste kommunikation reagieren."

somit wäre es optimal, wenn wir nach dem aufruf von "CUL_HM_ProcessCmdStack($hash)" auf eine antwort des vd prüfen, und vom ergebnis der prüfung abhängig die nächste eventTime generieren. entweder mit EventTime-generator eins oder zwei.
das würde aber bedeuten, man müsste einen moment warten, dann prüfen und die wartezeit mit in die berechnung der nächsten eventTime einbeziehen. hier fehlen mir die grundlagen, ob und wie man hier "warten" kann und/oder darf.

gruss frank

[martinp876]

Hi Frank,

warum nicht den timestamp prüfen. mit jedem ack auf ein setzen wird u.a. ValvePosition geändert. ReadingsTimestamp muss sich also geändert haben. Es müsste noch nicht einmal auf den Inhalt geprüft werden, nur auf gleichheit.

Allerdings verkompliziert sich das alles dann, da ein ACK für jeden VD auf der Liste geprüft werden muss und die Timer auseinander laufen. Faktisch muss man also für jeden VD einen timer laufen lassen, nicht für jeden TC. Oder den TC timer entsprechend berechnen...  dass er immer für den nächsten VD in seiner Liste aufgerüfen wird.

Gruss Martin