Datenempfang via CUL

Begonnen von RaspII, 04 Mai 2015, 21:53:49

Vorheriges Thema - Nächstes Thema

RaspII

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


RaspII

kaihs

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 an, vielleicht hilft dir das weiter.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

RaspII

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
RaspII

kaihs

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? 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
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

RaspII

#4
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)

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
RaspII

rudolfkoenig

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.

RaspII

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
RaspII

kaihs

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.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

RaspII

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:"

RaspII

kaihs

Ich denke das dient nur dazu eine Reihenfolge der Protokolle festzulegen, die nicht von den Namen der Module abhängt.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

rudolfkoenig

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.

kaihs

Das RPi add-on board verwendet den IR Empfang, dort gibt es keine Probleme mit dem funkempfang. Daher die Möglichkeit bitte nicht entfernen.
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

RaspII

#12
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)


RaspII

RaspII

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"
RaspII

RaspII

#14
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
RaspII