Datenempfang via CUL

[rudolfkoenig]

Was bewirkt folgender Eintrag bei CUL_Attr(@):

Diese Stelle wird aufgerufen, falls "attr CUL rfmode WMBus_S" aufgerufen wird, entweder in fhem.cfg oder vom Benutzer explizit.
Falls rfmode bereits gesetzt ist (initstring =~ m/brs/) dann muss man ja nichts machen.
Sonst wird geprueft, ob das Firmware WMBus unterstuetzt (CMDS =~ m/b/), und ob das CUL funktionsfaehig ist.
Wenn ja, dann wird Clients, MatchList und initString gesetzt, und das CUL umprogrammiert.

[RaspII]

Hi,

Bevor ich jetzt weiter im Blindflug unterwegs bin werde ich mich nochmal intensiv mit dem WMBUS Beispiel beschäftigen.
Und mein Perl know how vertiefen.
Eure Hinweise zeigen mir, dass ich die Abläufe noch nicht vestanden habe.
Ich melde mich wieder sobald ich die nächste Hürde genommen habe (das CUL.pm Modul dem KOPP_FC.pm Modul die Daten korrekt übergibt) oder zumindest etwas fundierter fragen kann.

Danke für die vielen guten Tipps, die werden mir dabei  eine gute Hilfe sein.

Gruß
RaspII

[RaspII]

Hi,
melde mich jetzt wieder zurück.
Nach einigen Abenden mit Perl Lektionen wurde ich einigermaßen erleuchtet.
Ich weiss jetzt z.B.  dass  "m/A/" nicht der komplette Suchstring von "=~ m/A/" ist, sondern "m//" die Match Funktionalität darstellt 
(Copy & Paste alleine hilft halt doch nicht immer).

Ich bin jetzt soweit, dass das Empfangstelegramm via der Module "CUL.PM" und fhem.pl in meiner "KOPP_FC_Parse" Funktion landen, d.h. der Match-Mechanismus (Matchlist etc.) funktioniert. den Rest bekomme ich mit Eurer Unterstützung  auch noch hin.

Bei meiner Fehlersuche ist mir noch was aufgefallen, vielleicht kann man das ja ändern:
Folgende Fehlermeldung wird aus mehreren Modulen geworfen wenn es keine passende Definition gibt oder wie bei mir die Matchliste noch nicht arbeitet, u.A. auch aus fhem.pl:
2015.05.14 11:46:41 3: CUL_0: Unknown code A0E24A01142624224B0590201000000::-103:CUL_0, help me!
Ich habe einige Zeit damit verbracht herauszubekommen auf welcher Ebene dieser Fehler letztendlich geworfen wird (und fhem.pl steht auch noch im übergeordneten Verzeichnis, dort hatte ich erst ganz zum Schluss gesucht.
Mein Vorschlag ist, dass man bei Fehlermeldungen künftig immer noch das Modul angibt, welches die Meldung getriggert hat, z.b.:
2015.05.14 11:46:41 3: CUL_0: Unknown code A0E24A01142624224B0590201000000::-103:CUL_0, help me! [fhem.pl]

So, dann mach ich mal weiter.
Gruß
RaspII

[RaspII]

Hallo nochmal,
Jetzt brauche ich doch noch einen Tipp.
Ich kann jetzt den vom Sender empfangenen Befehl  in einen Status umwandeln und auch an die FHEM Oberfläche bringen.
Als einfachen Test habe ich ein Device mit den Zuständen on und off definiert (siehe Anhang).
Das klappt soweit auch bestens.

Bei jedem Tastendruck des Senders ändert sich wie gewünscht der Zustand der Lampe in on und off, das nachfolgende Notify wird ebenfalls ausgeführt (nicht wundern, ich steuer damit einen zweiten FHEM Server an).

Drücke ich aber auf die Schaltflächen on oder off direkt in der Weboberfläche wird zwar der Notify korrekt ausgeführt, der Status der Lampe selbst ändert sich allerdings nicht (was unschön ist).

Evt. mach ich hier einen prinzipiellen Fehler oder in meiner "PM" Datei fehlen noch wesentliche Funktionen.

Wäre schön wenn jemand einen Tipp hat.

Hier noch der Auszug aus der zugehörigen fhem.cfg:

Code Auswählen Erweitern

# Test Empfang von Kopp Sender Taste2 Rad4
# ----------------------------------------
define Taste2Rad4 KOPP_FC 14 FA5E 02
attr Taste2Rad4 IODev CCD
attr Taste2Rad4 room Test
attr Taste2Rad4 group _Test_Empfangen
attr Taste2Rad4 eventMap on:on off:off
attr Taste2Rad4 webCmd on:off
attr Taste2Rad4 devStateIcon on:on off:off
define Taste2Rad4_In_Action notify Taste2Rad4 { fhem "set RPI2 cmd set Lichterkette $EVENT" }

[Wzut]

der Status der Lampe selbst ändert sich allerdings nicht (was unschön ist).
Evt. mach ich hier einen prinzipiellen Fehler oder in meiner "PM" Datei fehlen noch wesentliche Funktionen.

Ist das Kopp Protokoll ein "dummes" Protokoll , d.h. es gibt keine Rückmeldung vom Gerät nach einem on/off Schaltvorgang ?
Wenn ja , dann schau dir mal z.B. bei 10_IT oder auch 46_TRX_LIGHT das Ende der _Set Funktion an, dort wird das letzte Kommando mit Zeitstempel jeweils direkt in state geschrieben. 

[RaspII]

Hi,
ja, das Protokoll bestätigt das Telegramm nicht.
Hab Deinen Tipp ausprobiert, -> Klappt natürlich.

Müsste man nicht auch bei Define den Status erstmalig setzen?


Danke
RaspII

[Wzut]

Ja, machen andere Module auch so, setze da direkt state auf "defined" , "unknow" , "? ? ?"  oder  oder und mit dem ersten
Empfang bzw. Set Kommando wechselt er dann auf on bzw. off

[RaspII]

Hallo,
melde mich hier mit einem neuen Problem zurück.
Nachdem jetzt die Empfangsroutinen prinzipiell funktionieren bin ich über ein neues Problem gestolpert.

Ich wollte noch sicherstellen, dass der Status für alle in FHEM angelegten Devices mit identischem Code (solle alle auf die selbe Taste der Fernbedienung reagieren).
Habe dazu auch die entsprechenden Vorlagen gefunden und in mein Modul eingebaut.
Dazu habe ich in der  "_Define" Routine folgenden Code eingebaut:

Code Auswählen Erweitern


my $code  = uc("$transmittercode1 $keycode");
my $ncode = 1;
$hash->{CODE}{ $ncode++ } = $code;
$modules{KOPP_FC}{defptr}{$code}{$name} = $hash;
Log3 $name, 2, "KOPP_FC_Define: Modules: $modules{KOPP_FC}{defptr}{$code}{$name} Name: $name a[0]: $a[0] Transmittercode1: $transmittercode1 Keycode: $keycode Hash: $hash" ; 

AssignIoPort($hash);


Die als Ergebnis im Logfile folgenden korrekten Eintrag liefert:

2015.06.01 22:17:35 2: KOPP_FC_Define: Modules: HASH(0x2036100) Name: Dimmer a[0]: Dimmer Transmittercode1: FA5E Keycode: 65 Hash: HASH(0x2036100)
2015.06.01 22:17:35 2: KOPP_FC_Define: Modules: HASH(0x2052d38) Name: DimmerDevice a[0]: DimmerDevice Transmittercode1: FA5E Keycode: 65 Hash: HASH(0x2052d38)
2015.06.01 22:17:35 2: KOPP_FC_Define: Modules: HASH(0x2053728) Name: Taste2Rad4 a[0]: Taste2Rad4 Transmittercode1: FA5E Keycode: 14 Hash: HASH(0x2053728)
2015.06.01 22:17:35 2: KOPP_FC_Define: Modules: HASH(0x2053f28) Name: SenderNeuTaste1 a[0]: SenderNeuTaste1 Transmittercode1: F129 Keycode: 30 Hash: HASH(0x2053f28)
2015.06.01 22:17:35 2: KOPP_FC_Define: Modules: HASH(0x2054378) Name: SenderNeuTaste2 a[0]: SenderNeuTaste2 Transmittercode1: F129 Keycode: 20 Hash: HASH(0x2054378)

D.h. alle Module sind wie in der Config Datei angegeben korrekt gelistet, Name und a[0] waren nur 2 Methoden um den Namen zu lesen.

In "_Parse" Routine habe ich dann folgenden Code eingebaut:

Code Auswählen Erweitern


          my $code  = uc("$transmittercode1 $keycode");
my $rhash = $modules{KOPP_FC}{defptr}{$code};
my $rname = $rhash->{NAME}; # klappt nicht, ok, da Hash auf mehr Devices referenziert

# Look for all devices with the same code, and set state, (timestamp, not yet) variant 1: does not work ????
# ----------------------------------------------------------------------------
      if($rhash)
      {

my @list;
foreach my $n (keys %{ $rhash })
        {
                  my $lh = $rhash->{$n};
#                 $n = $lh->{NAME};        # Klappt nicht, da der Hash auch schrott enthält
                  return "" if(IsIgnored($n));              # Little strange.

  Log3 $name, 2, "KOPP_FC_Parse rname: $rname n: $n  lh: $lh";  # kann wieder Raus !!!! ### Claus

#                readingsSingleUpdate($lh, "state", $state, 1); # mal rauskommentiert damit kein Schrott passiert

push(@list, $n);
                }
return @list;
   }
   else
  {
    Log3 $name, 2, "KOPP_FC_Parse rhash not defined";  # kann wieder Raus !!!! ### Claus
   }



Als Ergebnis steht aber im Logfile:

2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: Dimmer  lh: HASH(0x2036100)
2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: CHANGEDWITHSTATE  lh: ARRAY(0x23076f8)
2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: READINGS  lh: HASH(0x228aac8)
2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: CHANGED  lh: ARRAY(0x22a0b68)
2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: STATE  lh: off
2015.06.01 22:31:16 2: KOPP_FC_Parse rname:  n: DimmerDevice  lh: HASH(0x2052d38)

Dimmer und DimmerDevice sind korrekt, alle anderen zurückgelieferten Devices wie "CHANGEDWITHSTATE" usw. sind aber schrott.
Diesen Schrott bekomme ich immer als Beigabe, egal welche Taste ich am Sender drücke (auch wenn diese als einzige Taste im Config File definiert ist. Das Ergebnis sieht dann z.B. so aus:

2015.06.01 22:01:35 2: KOPP_FC_Parse rname:  n: CHANGEDWITHSTATE  lh: ARRAY(0x28256b0)
2015.06.01 22:01:35 2: KOPP_FC_Parse rname:  n: READINGS  lh: HASH(0x2827520)
2015.06.01 22:01:35 2: KOPP_FC_Parse rname:  n: CHANGED  lh: ARRAY(0x2751c38)
2015.06.01 22:01:35 2: KOPP_FC_Parse rname:  n: STATE  lh: off
2015.06.01 22:01:35 2: KOPP_FC_Parse rname:  n: SenderNeuTaste1  lh: HASH(0x24cde28)

Hier ist jetzt "SenderNeuTaste1" der korrekte Eintrag, alles andere ist Schrott.

Einen Punkt muss ich hier erwähnen, da evt. relevant:
Ich habe bisher keine "_Undef"  Routine in meinem Modul, bin mir also nicht sicher ob sich in der Vergangenheit irgendwelcher Schrott angesammelt hat. "fhem.save" habe ich schon gelöscht, hilft nichts.

Vielleicht kann mir ja jemand den entscheidenden Tipp geben.
Ich suche mir gerade den Wolf

Als Vorlage hatte ich übrigens das FS20- sowie das Somfy Modul herangezogen, der genutze Code ist denke ich verstanden.

Gruß
RaspII

[rudolfkoenig]

Die $hash Eintraege von fhem.pl als Schrott zu bezeichnen ist nicht gerade hoeflich.

[RaspII]

Hallo Rudolf,
dafür erst mal "Entschuldigung !!".
Ich bin etwas entnervt, schon alleine Perl ist nicht einfach zu verstehen.
Ich hätte diese $hash Einträge an dieser Stelle nicht erwartet, sondern nur die Namen der Module mit identischem Code.

Aber Du hast mir schon geholfen. Nachdem ich jetzt wusste, dass die Einträge kein Schrott (nochmal sorry ) sind, habe ich mir meinen Code nochmal angeschaut.
Die Stelle an der ich den neuen Status stetze läuft über den falschen Hash.
(ich benutzte dafür $rhash anstelle von $lh, hab den Code mal rauskommentiert, jetzt ist die Liste wie erwartet).

Gruß
RaspII