Falsche Zeit am HM-TC-IT-WM-W-EU

[frank]

Japp. Ich hab die Code Stellen mal mit einer Log Message instrumentiert, mal sehen ob der Code bei HMLAN überhaupt ausgeführt wird.

du kannst auch über "attr <meinHMLAN> logIDs <meinTC>" beim hmlan, die zu loggenden rawmessages einstellen. dabei sieht man auch den timerequest.

das interessante wären aber "eigenständige" funksprüche des hmlan. also nicht von fhem ausgehend. diese werden dann wahrscheinlich nur durch ein zweites io, das nur am lauschen ist, wahrgenommen. vielleicht sogar idealerweise ein cul, der kein eq3-eigenleben führt.

[strauch]

Ich kann mal einen CUL 24h mitloggen lassen, wenn jemand anderes sich durch den Datenwust wühlen will?!

[frank]

Ich kann mal einen CUL 24h mitloggen lassen, wenn jemand anderes sich durch den Datenwust wühlen will?!

am besten mit verbose4 beim cul und anschliessend nach messages mit der hmid vom tc durchstöbern.

[strauch]

am besten mit verbose4 beim cul und anschliessend nach messages mit der hmid vom tc durchstöbern.

Ich werde das heute Abend mal starten und die passagen mit der ID eines tc hier posten. ok? Reichen 24h oder lieber mehr.

[frank]

ok? Reichen 24h oder lieber mehr.

du kannst ja erstmal 24h posten und trotzdem weiterlaufen lassen, falls nichts enthalten ist. wie gesagt, wäre es vielleicht sinnvoll, die systemzeit von fhem während des tests zu verstellen. dann läuft aber wahrscheinlich das grosse chaos bei dir. 

[strauch]

Ne das werde ich mir erstmal verkneifen . Zumal die Zeit vom debian automatisch synchronisiert.

[Cruiser79]

Code Auswählen Erweitern

    elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
      my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
      push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
      push @evtEt,[$shash,1,"time-request"];
    }

das sollte der entsprechende code von cul_hm zum handling des tc-it sein.
diese frage enttäuscht mich nun aber. hast du den thread nicht gelesen?   

es steht die these im raum, dass der hmlan eine eigene zeit hat, und diese eventuell eigenständig verteilt.

Klar habe ich den Thread gelesen, aber wohl die Thesen nicht als solche erkannt

Bei mir ist übrigens die letzten Tage die richtige Zeit zu sehen. Ich habe aber auch vorgestern FHEM ein paar Mal neu gestartet, da ich mit dem Floorplan gebastelt habe. Wird also wohl dann der Neustart-Effekt sein.

[strauch]

Bist du dir denn sicher das FHEM eine korrekte Uhrzeit hatte?

Mein logging läuft, ich hab einen HM-TC-IT-WM-W-EU solo laufen, also ohne Thermostate, da dürfte sich die uninteressante Kommunikation in Grenzen halten.
Jetzt suche ich noch eine Möglichkeiten alle Zeilen die eine bestime Zahlenkombi beinhalten oder eben nicht kopieren oder löschen zu können. Vermutlich geht das am ehesten mit VI. Vielleicht hat jemand einen Tipp?

[frank]

Jetzt suche ich noch eine Möglichkeiten alle Zeilen die eine bestime Zahlenkombi beinhalten oder eben nicht kopieren oder löschen zu können. Vermutlich geht das am ehesten mit VI. Vielleicht hat jemand einen Tipp?

als windows-user kann ich nur raten: eventuell geht was mit grep?

[strauch]

Ich hab auch Windows und OSX. Aber du hast recht. grep ist eine sehr gute Idee, das sollte klappen.

[MarcelK]

Also der Code in CUL_HM wird definitiv ausgeführt, was mich jetzt doch irgendwie wundert. Wenn ich autonomes Zeit-Handling in einer Firmware implementieren würde, dann würde ich aber auch dafür sorgen dass die Anfragen nicht mehr durchgereicht werden. Bin auf die Ergebnisse vom Logging gespannt.

[strauch]

Ich musste gerade paar mals mein FHEM Server neustarten, das dürfte ein paar getconfig anfragen im Log nach sich ziehen... hoffe das bringt nichts durcheinander, müsst eich mal 24h die Finger von allem lassen .

[strauch]

Hier gibt es schonmal einen Teil.... weiß überhaupt jemand wonach zu suchen ist?

[frank]

2015.01.23 19:04:17.821 4: CUL_Parse: CUL_0 A 09 02 A03F 2B0AEC F11134 4C -36

2015.01.23 19:04:17.950 4: CUL_Parse: CUL_0 A 0F 02 803F F11134 2B0AEC 02041C553B920C -68
2015.01.23 19:04:18.223 4: CUL_Parse: CUL_0 A 0F 02 803F F11134 2B0AEC 02041C553B910E -67

das ist der entscheidende abschnitt. 2B0AEC (TC) sendet mit befehl A03F an F11134 (Zentrale) den time-request. daraufhin gibt es 2 antworten 803F. die zeit in sec seit 2000 ist blau dargestellt.

nach meinem verständnis unterscheiden sich die zeiten um eine sekunde. warum sollte fhem also 2 mal antworten mit 2 unterschiedlichen zeiten? ich würde sagen eine antwort ist vom hmlan direkt, die andere von fhem. auch seltsam, dass die spätere antwort eine sekunde weniger hat. und beide antworten haben trotzdem die selbe msgnummer 02.

für den nächsten test kannst du ruhig verbose=4 beim cul machen. jetzt wäre ein test mit geänderter systemzeit fällig, um das zu bestätigen. auch eine logzeile in cul_hm, die den sekundenwert ins log schreibt wäre sinnvoll. etwa so:

Code Auswählen Erweitern

    elsif($mTp eq "3F" && $ioId eq $dst) { # Timestamp request
      my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
      push @ack,$shash,"${mNo}803F$ioId${src}0204$s2000";
      push @evtEt,[$shash,1,"time-request"];

     ####################################################
      Log 1,"----- time-request----- sekunden: $s2000";
     ####################################################
    }

[strauch]

Soll ich parallel auf dem haupsystem mitloggen man müsste ja den Unterschied sehen. Zeit verstellen will ich nicht unbedingt machen.

Gesendet von meinem Nexus 4 mit Tapatalk