Hallo,
ich habe für die culfw ein Modul entwickelt das Daten versenden und inzwischen auch empfangen kann (Kopp Free Control System).
Die Firmware (Senden) läuft bei mir seit ca. 1/2 Jahr stabil, seit kurzem ist auch der Empfangsmode in der culfw enthalten und läuft bisher problemlos.
Die "Sendefunktion" habe ich auch als Prototyp in FHEM integriert (10_KOPP_FC.pm), beim Einbinden des Empfangsmodules musste ich allerdings die Waffen strecken (zu kompliziert weil ich die Mechanismen noch nicht komplett verstanden habe).
Aus der "Development Modul Intro" (Rudolf, danke für die gelungene Dokumentation) habe ich entnommen, dass ich mich vermutlich um ein zweistufiges Modell kümmern muss.
Ich vermute mal, dass ich dazu auch das Modul 00_CUL.pm anpassen muss, vermutlich mindestens die Abschnitte
"my $client..." und
"my %matchList..."
my $clientsSlowRF = ":FS20:FHT.*:KS300:USF1000:BS:HMS: ".
":CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: ".
":ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: ".
":STACKABLE_CC:CUL_RFR::CUL_TCM97001:";
my $clientsHomeMatic = ":CUL_HM:HMS:CUL_IR:STACKABLE_CC:";
my $clientsMAX = ":CUL_MAX:HMS:CUL_IR:STACKABLE_CC:";
my $clientsWMBus = ":WMBUS:HMS:CUL_IR:STACKABLE_CC:";
my %matchListSlowRF = (
"1:USF1000" => "^81..(04|0c)..0101a001a5ceaa00....",
"2:BS" => "^81..(04|0c)..0101a001a5cf",
"3:FS20" => "^81..(04|0c)..0101a001",
"4:FHT" => "^81..(04|09|0d)..(0909a001|83098301|c409c401)..",
"5:KS300" => "^810d04..4027a001",
"6:CUL_WS" => "^K.....",
"7:CUL_EM" => "^E0.................\$",
"8:HMS" => "^810e04....(1|5|9).a001",
"9:CUL_FHTTK" => "^T[A-F0-9]{8}",
"A:CUL_RFR" => "^[0-9A-F]{4}U.",
"B:CUL_HOERMANN"=> "^R..........",
"C:ESA2000" => "^S................................\$",
"D:CUL_IR" => "^I............",
"E:CUL_TX" => "^TX[A-F0-9]{10}",
"F:Revolt" => "^r......................\$",
"G:IT" => "^i......",
"H:STACKABLE_CC"=>"^\\*",
"I:UNIRoll" => "^[0-9A-F]{5}(B|D|E)",
"J:SOMFY" => "^Y[r|t|s]:?[A-F0-9]+",
"K:CUL_TCM97001" => "^s[A-F0-9]+",
);
my %matchListHomeMatic = (
"1:CUL_HM" => "^A....................",
"8:HMS" => "^810e04....(1|5|9).a001", # CUNO OneWire HMS Emulation
"D:CUL_IR" => "^I............",
"H:STACKABLE_CC"=>"^\\*",
);
my %matchListMAX = (
"1:CUL_MAX" => "^Z........................",
"8:HMS" => "^810e04....(1|5|9).a001", # CUNO OneWire HMS Emulation
"D:CUL_IR" => "^I............",
"H:STACKABLE_CC"=>"^\\*",
);
my %matchListWMBus = (
"J:WMBUS" => "^b.*",
"8:HMS" => "^810e04....(1|5|9).a001", # CUNO OneWire HMS Emulation
"D:CUL_IR" => "^I............",
"H:STACKABLE_CC"=>"^\\*",
);
Damit bin ich allerdings mit meinem Latein am Ende.
Bevor ich in irgendwelchen Modulen ein Chaos anrichte (mach ich natürlich nicht), an dieser Stelle mein Ruf nach Unterstützung.
Gibt es schon eine Doku die mir hier weiterhilft oder kann mir vielleicht jemand "Hilfestellung" geben, damit ich die nächste Schritte
(Schritt für Schritt) unternehmen kann. (Vielleicht kann man damit auch die Doku für das zweistufige Modell nachziehen, ich helfe auch gerne dabei).
An dieser Stelle nochmal ein dickes Lob an die Community, meine bisherige Arbeit wäre ohne Eure Unterstützung nicht möglich gewesen.
Gruß
RaspII
Ich habe etwas ähnliches für den Empfang von WMBUS gemacht.
Schau dir mal den Patch in http://forum.fhem.de/index.php/topic,25946.msg189715.html#msg189715 (http://forum.fhem.de/index.php/topic,25946.msg189715.html#msg189715) an, vielleicht hilft dir das weiter.
Hm,
hab mir mal den ersten Patch angeschaut.
Sehe ich das richtig, Dein Modul ist Bestandteil des slowRF Protokolls?
(das macht das Ganze vermutlich noch komplizierter).
Ich gehe bisher davon aus, dass neben meinem Modul kein weiterer Empfangsmode aktiv ist und empfange die Daten im "FIFO Mode".
Würde mich freuen, wenn jemand ein paar Sätze schreibt und erklärt was er getan hat (nur den Code lesen ist für einen nicht Pearl Experten wie mich extrem schwierig).
Gruß
RaspII
Rudolf ist da sicher der kompetentere Ansprechpartner, aber ich versuche es trotzdem mal.
Muss die culfw für das FC-Protokoll in einen besonderen Modus versetzt werden und du schaltest dabei aktiv alle anderen Protokolle aus, siehe http://fhem.de/commandref.html#rfmode (http://fhem.de/commandref.html#rfmode)? Wenn nicht, ist dein Protokoll nur ein weiteres das zu den bereits implementierten empfangen wird.
Du musst daher die matchlist das passenden rfModes erweitern.
Wird dein Protokoll in der culfw empfangen, so muss die Ausgabe mit einem regulären Ausdruck eindeutig identifizierbar sein, meist dadurch dass sie mit einem bestimmten Buchstaben beginnt.
Angenommen dein Protokoll wird im slowRF Modus empfangen und verwendet 'k' als Kennzeichen und dein Modul heißt KOPP_FC, so muss die vorletzte Zeile ergänzt werden:
my %matchListSlowRF = (
"1:USF1000" => "^81..(04|0c)..0101a001a5ceaa00....",
"2:BS" => "^81..(04|0c)..0101a001a5cf",
"3:FS20" => "^81..(04|0c)..0101a001",
"4:FHT" => "^81..(04|09|0d)..(0909a001|83098301|c409c401)..",
"5:KS300" => "^810d04..4027a001",
"6:CUL_WS" => "^K.....",
"7:CUL_EM" => "^E0.................\$",
"8:HMS" => "^810e04....(1|5|9).a001",
"9:CUL_FHTTK" => "^T[A-F0-9]{8}",
"A:CUL_RFR" => "^[0-9A-F]{4}U.",
"B:CUL_HOERMANN"=> "^R..........",
"C:ESA2000" => "^S................................\$",
"D:CUL_IR" => "^I............",
"E:CUL_TX" => "^TX[A-F0-9]{10}",
"F:Revolt" => "^r......................\$",
"G:IT" => "^i......",
"H:STACKABLE_CC"=>"^\\*",
"I:UNIRoll" => "^[0-9A-F]{5}(B|D|E)",
"J:SOMFY" => "^Y[r|t|s]:?[A-F0-9]+",
"K:CUL_TCM97001" => "^s[A-F0-9]+",
"L:KOPP_FC" => "^k.*",
);
Damit ist schon mal bekannt, welches Modul zu diesen Nachrichten gehört.
Weiterhin muss noch etwas in CUL_Parse ergänzt werden, damit dort die Nachricht nicht als unbekannt betrachtet wird.
} elsif($fn eq "k" && $len >= 21) { # Kopp FC, Länge anpassen!
;
Das müsste alles Notwendige in CUL.pm sein, den Rest must du in der Parse Funktion deines Moduls implementieren.
Als Beispiel kannst du dir die Module ansehen, die schon in CUL.pm eingetragen sind.
Kai
Hallo Kai,
das hilft mir schon mal weiter.
Ich habe mein Empfangsmodul in der culfw im Packetmode implementiert
(siehe: http://forum.fhem.de/index.php/topic,33548.msg287645.html#msg287645 (http://forum.fhem.de/index.php/topic,33548.msg287645.html#msg287645))
Laut Rudolf ist das nicht der slowRF Modus.
Ich vermute mal Deine Anleitung passt trotzdem, nur darf ich nicht die matchListSlofRF nutzen sondern muss mir eine eigene matchListKopp anlegen.
Unklar ist ausserdem, ob ich dann den Eintrag in "CUL_Parse" noch wie von Dir geschrieben benötige.
Solltest Du die Antwort kennen, nur her damit, ansonsten werde ich mal sehen ob ich aus dem Code schlau werde.
Ach ja, beim definieren des CUL setzte ich das Attribut rfmode überhaupt nicht, ich initialisiere die CC1101 Register direkt in der Firmware,
kann durchaus sein dass ich da was falsch mache und noch dafür sorgen muss dass alle anderen Prototkolle abgeschaltet werden.
Danke vorab
RaspII
Paketmode ist _nicht_ SlowRF, CUL.pm muss angepasst werden.
Was ich auf die schnelle gesehen habe:
- $clientsKnopp anlegen
- %matchlistKnopp anlegen
- attrList fuer rfMode erweitern
- CUL_Parse: RSSI regexp, bzw. typ/Laengenpruefung in der IF-Kaskade.
- CUL_Attr Eintag: rfmode Argument pruefen, Wechsel in culfw einleiten, Clients/MatchList aktivieren
- Doku fuer slowRf
Alles relativ einfach als Copy&Paste von WMBus/MAX.
Hi,
danke für die Antwort.
Bin grad am einbauen und habe noch eine Frage:
Warum gibt es sowohl bei den matchListen von
"SlowRF", "Homematic", "MAX" und "WMBus"
jeweils die Einträge für:
"8:HMS" => "^810e04....(1|5|9).a001", # CUNO OneWire HMS Emulation
"D:CUL_IR" => "^I............",
"H:STACKABLE_CC"=>"^\\*",
?
my %matchListWMBus = (
"J:WMBUS" => "^b.*",
"8:HMS" => "^810e04....(1|5|9).a001", # CUNO OneWire HMS Emulation
"D:CUL_IR" => "^I............",
"H:STACKABLE_CC"=>"^\\*",
);
Kann mir das beim besten Willen nicht erklären, werde es aber mal sicherheitshalber auch beim Kopp Modul übernehmen.
Gruß
RaspII
Es gibt Geräte die mehr als die Funkschnittstelle haben, z. B. Infrarot oder Onewire. Deren Daten können daher immer zusätzlich empfangen werden.
klappt ja super, verstehe.
Kannst Du mir auch noch sagen was das jeweilige Zeichen am Anfang der Zeile bedeudet, also z.B. bei "J:WMBUS" => "^b.*" das "J:"
Ich denke das dient nur dazu eine Reihenfolge der Protokolle festzulegen, die nicht von den Namen der Module abhängt.
HMS ist in diesem Fall wegen der HMS-Emulation von OneWire Geraeten drin, und IR koennte theoretisch von manchen CUNOs auch noch parallel empfangen werden. Theoretisch, weil IR-Empfang mWn die Timings beim Analysieren der Funkprotokolle stoert. Verwendet jemand noch CUNO mit IR Empfang?
Die matchList Eintraege werden nach der ersten Buchstabe sortiert, und die Regexps in dieser Reihenfolge getestet. Es gibt einen Fall, wo das relevant ist: USF1000, BS und FS20.
Das RPi add-on board verwendet den IR Empfang, dort gibt es keine Probleme mit dem funkempfang. Daher die Möglichkeit bitte nicht entfernen.
ok, einen kleinen Schritt bin ich weiter.
In der Log Datei hatte ich ohne die obigen Modificationen nur die Meldung:
2015.05.03 20:26:24 2: CCD: unknown message kr07FA5EDA05CC0F0217
bekommen.
Seit eben sieht es so aus:
2015.05.05 23:08:45 2: CCD: unknown message krS-ReceiveStart
2015.05.05 22:57:14 3: CCD: Unknown code kr07FA5EDD05CC0F0210, help me!
Ich habe in CUL_Parse folgende Zeilen eingefügt:
} elsif($fn eq "t" && $len >= 5) { # TX3
$dmsg = "TX".substr($dmsg,1); # t.* is occupied by FHTTK
} elsif($fn eq "s" && $len >= 5) { # CUL_TCM97001
;
} elsif($fn eq "k" && $len >= 20) { # KOPP_FC
;
} else {
DoTrigger($name, "UNKNOWNCODE $dmsg");
Log3 $name, 2, "$name: unknown message $dmsg";
return;
D.h. Sendet meine culfw weniger als 20 Zeichen kommt noch der alte Log Eintrag,
Wenn ich 20 Zeichen sende (das ist der echte Sendercode), kommt jetzt unknown code anstelle von unknown message.
Hätte zwar erwartet, dass der "else Pfad" jetzt gar nicht mehr durchlaufen wird, habe da aber vermutlich was übersehen.
Nachtrag:
ok, liegt vermutlich daran dass ich folgende Anweisung von Rudolf übersehen habe:
- CUL_Attr Eintag: rfmode Argument pruefen, Wechsel in culfw einleiten, Clients/MatchList aktivieren
probier ich noch aus (evt. nicht mehr heute)
So eine Frage hab ich noch.
Was bewirkt folgender Eintrag bei CUL_Attr(@):
} elsif($aVal eq "WMBus_S") {
return if($hash->{initString} =~ m/brs/);
if($hash->{CMDS} =~ m/b/ || IsDummy($hash->{NAME}) || !$hash->{FD}) {
$hash->{Clients} = $clientsWMBus;
$hash->{MatchList} = \%matchListWMBus;
$hash->{initString} = "X21\nbrs"; # Use S-Mode, X21 is needed for RSSI reporting
CUL_WriteInit($hash);
} else {
Log3 $name, 2, $msg;
return $msg;
}
Woher kommt der Code m/brs/ im Initstring bzw. wie wird dieser angelegt bzw. was passiert hier genau?
Was genau passiert bei der Abfrage {CMDS}=~m/b/
(ich hätte beim Assembler programmieren bleiben sollen :-\ )
Ach ja, nach dem ich jetzt ein rfmode Attribut mit Inhalt KOPP_FC sowie die zugehörigen Zeilen in CUL.PM angelegt habe bekomme ich jetzt
keine Meldung "Unknown code" in der Log Datei mehr zu sehen, dafür aber jede Menge Meldungen wie "unknown message 00 Checksum Error"
f~##
sieht gerade so aus, dass ich mein CCD Modul gekillt habe.
Die Checksummenfehler kamen nach völligem Rückbau der SW immer noch.
Ich hab dann geprüft ob ich noch senden kann, das ging genau 1x, seither sendet das CCD Modul nichts mehr.
Anscheinend ist der HF Teil jetzt defekt, die Kopp- Kommandos kann ich per Terminal noch absetzen (und bekomme auch eine Bestätigung), gesendet wird aber nichts.
Mit meinem CUL klappt es noch einwandfrei.
Hatte jemand schon ähnliche Probleme?
(das hat sich ja gelohnt)
Nachtrag:
hat sich erledigt, offensichtlich merkt sich dass CCD die Verstärkereinstellung, und die wurde durch "Schrottkommando's" überschrieben.
Nach "x09" klappt wieder alles
ZitatWas 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.
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
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
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:
# 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" }
Zitat von: RaspII am 15 Mai 2015, 00:15:50
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.
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
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
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:
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:
Zitat2015.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:
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:
Zitat
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:
Zitat
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
Die $hash Eintraege von fhem.pl als Schrott zu bezeichnen ist nicht gerade hoeflich.
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