Probleme beim ACK (Version 5866 -> 5912)

[martinp876]

Hallo Andre,

Die Zeit ist ja scheinbar schon zwischen CUL_Parse und CUL_HM_Parse weg, oder?

korrekt. Aus den vorigen Logs wissen wir, das CUL an den Kernal "übergeben" hat - genau an "Dispatch" in fhem.pl .
Dieser ruft den CUL_HM parser auf - da sollte nicht viel Zeit vergehen.

Wir müssen also die Dispatch funktion in fhem.pl analysieren. Die probiert, ob jemand die message brauchen kann - und da braucht wohl jemand recht lange. Das könnte dann schon eines der anderen Module sein

Gruß Martin

[Andre]

Hi,

ich versuche jetzt das Timing genauer zu untersuchen, nur leider habe ich nicht immer Zugriff auf die Hardware (den Sensor). Es wäre super hilfreich, wenn ich die Message eines Fenstersensors simulieren könnte. Kann ich ein "dummy" Device in FHEM anlegen, welches sich so verhält wie ein Fenstersensor? Per webCmd könnte ich dann open und close simulieren und die Messages loggen. Es müssten natürlich echte Messages gesendet werden. Gibt es sowas? Ist hoffentlich keine komplett sinnlose Frage

Grüße
Andre

[martinp876]

perl ist da recht einfach zu stimulieren:

simuliere Close:
{my $in = "myCul";;CUL_Parse($defs{$in},$defs{$in},$in,"A0C89A4411CF75BF110340107000D");;return}

simuliere Open:
{my $in = "myCUL";;CUL_Parse($defs{$in},$defs{$in},$in,"A0C89A4411CF75BF11034010CC813");;return}

[Andre]

Cool, das ist der Bringer, Danke!
Beim Close bekomme ich allerdings ein Unknown code,...,help me! Muss ich den noch anpassen?

Gruß
André

[Andre]

Hi Martin,

ich habe ein paar Vergleiche mit dem Open Dummy angestellt. Für mich sieht es so aus, als wenn das Problem mit der Version 6030 wieder behoben ist. In Version 6008 ist es noch "Buggy". Hast Du da direkt eine Idee?

Da die Zeit ja in Dispatch() in fhem.pl liegenbleibt, habe ich da ein paar Messungen gemacht, und es sieht so aus, als ob die Zeit in der Funktion computeClientArray($$) verloren geht:

Code Auswählen Erweitern


2014.06.02 17:27:18.058 1: myCUL Before computeClientArray
2014.06.02 17:27:18.227 1: myCUL After computeClientArray


In der Version 6008 von CUL_HM benötigt der Aufruf bei jedem Mal ~175ms, in der Version 6030 nur der erste Aufruf, alle nachfolgenden Aufrufe sind <10ms:

Code Auswählen Erweitern


2014.06.02 17:28:30.904 1: myCUL Before computeClientArray
2014.06.02 17:28:30.907 1: myCUL After computeClientArray


Erscheint das plausibel oder doch kompletter Unsinn? Ich kann keine entsprechende Änderung in 10_CUL_HM.pm erkennen...

Gruß
André

[martinp876]

Die einzige Timing-änderung die mir bekannt ist, war das handling von "sortRooms". Das ist - je nach länge der Liste der Rooms - um faktor 10-20 beschleunigt worden.

in HM wurde nichts gemacht. War ja auch nicht das Problem.

[Andre]

Hallo Martin,

ist ja mittlerweile schon gelöst, aber da ich es mir solange angeschaut hatte, wollte ich es noch verstehen. Die relevante Änderung in 10_CUL_HM.pm (6008 -> 6030), die das Problem mit dem Timing fixt, ist folgende:

Vorher (6008). Hier wird immer AssignIoPort im Kernel aufgerufen, auch wenn sich das IODev nicht ändert:

Code Auswählen Erweitern


  # not assigned thru CCU - try normal
  my $dIo = AttrVal($hn,"IODev","");
  if ($dIo && $defs{$dIo} && $dIo ne $hash->{IODev}->{NAME}){
    $hash->{IODev} = $defs{$dIo};
  }
  else{
    AssignIoPort($hash);#let kernal decide
  }


Nachher (6030). Hier wird AssignIoPort im Kernel nur aufgerufen, wenn keins (?) definiert ist.

Code Auswählen Erweitern


  # not assigned thru CCU - try normal
  my $dIo = AttrVal($hash->{NAME},"IODev","");
  if ($defs{$dIo}){
    if($dIo ne $hash->{IODev}->{NAME}){
      $hash->{IODev} = $defs{$dIo};
    }
  }
  else{
    AssignIoPort($hash);#let kernal decide
  }


AssignIoPort wiederum sorgt im Kernel dafür, dass computeClientArray() in Dispatch jedes Mal aufgerufen wird, da .clientArray in AssignIoPort gelöscht wird.

Relevanter Teil in Dispatch():

Code Auswählen Erweitern


my $clientArray = $hash->{".clientArray"};
$clientArray = computeClientArray($hash, $module) if(!$clientArray);


Der Aufruf von computeClientArray benötigt (zumindest bei mir) immer ~175ms, daher war das Timing jedes Mal off. Ist vielleicht interessant falls es in ähnlicher Form nochmal auftaucht.

Eine offene Frage habe ich noch. Das Simulieren des Öffnens funktioniert ja wunderbar, nur beim Schließen bekomme ich weiterhin "Unknown code,...,help me!". Ich habe auch mal eine andere, echte Message für das Öffnen und Schließen kopiert und getestet, da geht jeweils auch nur "Öffnen". Hast Du da eine Idee woran das liegt?

Vielen (vielen) Dank für Deine Hilfe!

Grüße
Andre

[martinp876]

Hallo Andre,

habe ich nicht - hat bei mir auch funktioniert.
simuliere Close:
{my $in = "myCul";;CUL_Parse($defs{$in},$defs{$in},$in,"A0C89A4411CF75BF110340107000D");;return}

simuliere Open:
{my $in = "myCUL";;CUL_Parse($defs{$in},$defs{$in},$in,"A0C89A4411CF75BF11034010CC813");;return}

die messages müssen sich eigentlich nur in 00 (0=>0%=>zu)
und C8 (200=>100%=>offen)
underscheiden.
Dass es bei dir nicht funktioniert bedeuted, dass keiner (auch nicht CUL_HM) die message bearbeitet hat. Wichtig ist, dass die Adressen und flags gleich sind

A0CnnA4411CF75BF1103401bbC8xx
nn = message nummer
bb = nummer des Button events
xx = egal, nicht dekodiert

Ich vermute, du hast einen kopierfehler drin

Gruss Martin

[Andre]

Hi Martin,

musste lange scharf hinschauen 

{my $in = "myCul";;CUL_Parse($defs{$in},$defs{$in},$in,"A0C89A4411CF75BF110340107000D");;return}

Danke für die Erläuterung.

Gruß
Martin