Kopp free control

[Andreas_]

Ich möchte folgende Aufgabe lösen:

9 Kopp Free control Rolladensteuerungen (Funk 868MHZ) sollen über das Internet geschaltet werden können.

Die von der Firma Kopp dazu angekündigte "home Control"-Einheit wird mangels Interesse wohl nicht produziert.

Ich suche also eine Einheit, die auf der einen Seite internetfähig ist und auf der anderen Seite einen 868MHZ Sender besitzt, der verschiedene einzulernende Codes sendet.

Gibt es so etwas?

Ich bin für jeden Hinweis dankbar, bin aber kein hardcore-Programmierer sondern eher Elektroniker. DANKE.

[UliM]

Hi,
dafür müsste jemand das Funkprotokoll von Kopp entschlüsseln und ein fhem-Modul bauen.
Mit Anlernen gibt's nix.

Falls Du eine Fernbedienung für die Dinger hast, könntest Du die Fernbedienungs-Statendrücke per Arduino oder netIO steuern - dazu musst Du aber an Deiner Fernsteuerung rumlöten.

Nen anderen Weg wüsste ich jetzt nicht....

=8-)

[Andreas_]

Herzlichen Dank für die Idee.

Ich habe versucht, die Fernbedienungen an einem Hörmann Codeschloss einzulernen,,, das hat nicht funktioniert..

Das ist ja ein einlernbarer Sender mit 868MHZ... aber scheinbar ist Kopp wohl doch was ganz eigenes.

Vielleicht hat jemand noch ne Idee..

[Andreas_]

Ich habe mittlerweile folgende Seite entdeckt:
http://www.bepeppered.net/2013/03/19/funkdaten-mitloggen-und-simulieren/#permalink

hier wird beschrieben, wie man so ein Funksignal analysieren kann.

Mit Hilfe eines Freundes werde ich mal versuchen, ob ich die Kopp-Sender einlesen kann.

Nun habe ich eine weitere Frage:

Wie sendet man nun mit Hilfe von FHEM solche Signale?

Ich möchte dazu die Fritzbox 7390 nutzen

Wie fügt man den Sendebefehl in eine App ein?


Sollte es gelingen, hier eine Lösung zu finden, könnten mit Hilfe dieser eventuell sehr viele Komponenten eingelesen und verwendet werden können.

Wie bereits erwähnt, ich bin eher Laie. Herzlichen Dank.

[UliM]

Moin,
schau Dir am besten vorjandene Module an zu einem Hardwaresystem, das Du selbst verwendest, also zB FS20 oder HomeMatic oder MAX.
Möglicherweise müsste dazu auch due CUL-Firmware erweitert werden.
Gruß, Uli

[Andreas_]

aktueller Stand:Nächste Woche werde ich die Sendedaten der Kopp.-Taster auslesen.
Nun suche ich eine Möglichkeit mit Fhem diese Datei zu senden.
ich will die Fritzbox 7390 und den CUL verwenden.

hat jemand eine Anleitung wie ich dieses neue Gerät in Fhem definiere?

[Puschel74]

Hallo,

Nun suche ich eine Möglichkeit mit Fhem diese Datei zu senden.

Es kann durchaus sein das du die Firmware des CUL entsprechend umschreiben und neu flashen wirst müssen.
Mal eben so auf die schnelle das Funkptotokoll aufzeichnen und die Bitfolge wieder aussenden wird eher nicht zum Ziel führen.
Der CUL muss das ja auch senden können und da müssen schon einige Faktoren zueinander passen und nicht nur die Frequenz stimmen.

Grüße

[@MosWare]

Bei Kopp ist der CC1150 verbaut, Bei CUL V3 der CC1101
Den Unterschied kenne ich nicht.
Ich könnte die Funkstrecke für die Protokollanalyse erst mal weglassen und vor dem CC1150 bzw nach dem µC mit meinem Logic-Analysator
ran gehen, wenn mir jemand sagen kann an welchen Pins s. Foto.

Die Aufzeichnung könnt Ihr mit der kostenlosen Software ansehen:

http://www.saleae.com/downloads

Beste Grüße
@MosWare

[lilustig]

Hallo ich besitze auch mehrere FreeControl-Sender/Empfänger gibt es da schon eine Lösung?.

CUL V3 habe ich mir auch schon zugelegt.

Gruß und danke im voraus.

[Andreas_]

wir haben mal ein paar Bedienungen ausgelesen.Aber noch keine Simulation odet gar Anbindung an fhem ... die oben genannte Anleitung funktioniert zum auslesen. Allerdings hat mir ein Linuxspezialist geholfen. ..

Probier mal das auslesen und das simulieren selbst aus,  denn Du brauchst ja deine Codes nachher sowieso. Der Freund bastelt mir jetzt erst mal nen linuxrechner damit ich Zuhause auslesen und simulieren kann.

[gemx]

Hallo zusammen,

bin  neu hier und versuche gerade mich einzulesen.
Da ich bereits eine Rolladensteuerung per Kopp FreeControl habe, würde ich diese ebenfalls gerne auf FHEM umschwenken.

Bei der ganzen Sucherei ist mir EZcontrol aufgefallen. Das ist im prinzip auch nur ein CUL mit ein bischen FrontEnd Software.
Dort wird Kopp seid einigen Releases unterstützt.

Vielleicht könnten die "Macher" von FHEM mal ganz offiziell dort anfragen, ob sie vielleicht mit der Anbindung rausrücken.

[mike1098]

Hallo,

Ich bin auch neu hier und habe auch einiges von Kopp FreeControl. Ich würde mich sehr freuen wenn dieses bald unterstützt würde.

Gruss

Mike

[RaspII]

Hallo zusammen,
sieht so aus als wenn wir die selbe Idee / Probleme haben.
Ich möchte meine Kopp Haustechnik via RaspberryPi fernzusteuern.
Ich benutze dazu ein RFM12B Funkmodul.

Ich kann inzwischen die Signale der Kopp Sender empfangen (868,3 MHz, die Datenübertragung selbst läuft mit ca. 4,8 kBaud (4,789 kBaud um genau zu sein)).
Der Sender beginnt immer mit ca. 17 x AA Pattern, danach kommen die unterschiedlichen Datenblöcke.
Ich habe auch schon herausgefunden wie der eigentliche Tastencode übertragen wird, allerdings werden vom Sender mindestens 4 verschiedene Packete gesendet die ich nicht erklären kann.  Den ersten Block habe ich weitgehend verstanden (siehe angehängte Excel Datei), die weiteren Blöcke kann ich zur Zeit noch nicht interpretieren.

Der RFM12B Baustein empfängt immer Daten, auch wenn der Handsender nichts sendet (vermutlich wird die Empfindlichkeit aufgeregelt). Das führt dazu, dass zwischen den übertragenen Blöcken immer wieder eine Menge unsinniger Daten empfangen werden.

Ich habe eine Excel Datei mit meinen aufbereiteten Mitschnitten anghängt, aktiviert man die Macros sieht man berechnete Checksummen (in Grau hinterlegten Feldern).
Bei Block 1 ist diese Checksumme jeweils passend zum letzten Byte eines Blockes, bei den weiteren Blöcken ist die Checksumme manchmal nur in einem Nibble zum letzen Byte identisch.

Vermutlich muss ich meine Aktivitäten noch etwas genauer beschreiben damit ihr was damit anfangen könnt, bin aber mit meiner Zeit knapp bemessen.
Vielleicht versteht ja jemand von euch die Bedeutung der gesendeten Daten (Block 2, 3 und 4).


RaspII

[Andreas_]

Ich gebe zu, ich hab das nicht verstanden, was Du Dir erarbeitet hast

Das mit der Baudrate ist interessant, ich warte grade auf Support um ein Script zu erstellen, welches den Datenstrom, den wir mit dem CUL aufnehmen konnten, aneinander reiht um das mal zu interpretieren. Da ist die Zeitbasis ein guter Hinweis.

Support von David Pauli, der ja ne tolle Seite zum Protokoll auslesen geschrieben hat, kriege ich trotz mehrfacher Nachfrage leider nicht.

Bei meinen Rollladensendern ist jedoch das Protokoll jedes Tastendruckes anders. Ich kann noch keine Systematik erkennen, schon gar nicht, das mehrfach das selbe gesendet wird.

Ich spreche hier von kurzem drücken, welches den Rollladen ganz hoch oder ganz runter fährt. Langes drücken der Taste hat ja ne andere Funktion (Rolladen läuft, solange die Taste gedrückt ist).....

[Andreas_]

Ich habe erst mal kapituliert. Das Protokoll entschlüsseln, die Programmiererei,, das ist doch momentan zu heftig. Deshalb habe ich ne Fernbedienung von Kopp mit nem homematic-Relaismodul angesteuert.
Das hochfahren ging sofort, das runterfahren hat mich 3 Tage rumprobieren gekostet. Der Abwärtstaster geht auf einen INT. Eingang des Prozessors, der sehr empfindlich gegen prellen ist. Ich musste einen kleinen Kondensator parallel zu  den Anschlussklemmen des Modul einbauen - es hat nicht gereicht, den selben Kondensator auf der Platine parallel zum Taster anzuschliessen!!! Das ist schwer nachvollziehbar. Zudem braucht es länger bis das Ab-Signal gesendet wird, als das Auf-Signal.

Nun habe ich mit der ANDFHEM App ne Zeituhr gemacht und steuere die Relais jeweils 55 Sekunden an. Das funktioniert. Das Relaismodul von Homematic war nach 2 Minuten eingelernt - ich bin begeistert von homematic!

Ich gebe zu, dass bei allem technischen Interesse mir die Zeit zu schade ist, an dem Kopp-Protokoll ewig rumzumurksen. Denn dann hat man ja immer noch kein FHEM-Modul.

Als Projekt bleibe ich dran, denn grundsätzlich wäre es toll, wenn es ein Software-Modul für FHEM gäbe, das Protokolle aufzeichnet und auf Abruf wieder sendet.
Die Idee reizt mich und mit dem Cul-Stick muss das auch gehen. Es gäbe FHEM bestimmt einen großen Zulauf.

Allerdings bin ich momentan fachlich dazu nicht in der Lage. Danke für den tollen Support hier, auch wenn es dieses Problem nicht gelöst hat.

Vielleicht findet sich hier jemand, der ein Skript schreiben kann, um Daten aufzunehmen und diese mit FHEM zu senden.

Das Protokoll ist dann völlig wurscht, wenn ich die Bitfolge sniffe und 1:1 wieder so sende. Abgesehen von Wechselcodesendern, da funktioniert es natürlich nicht. Würde mich freuen, wenn sich jemand meldet und meine Idee mit Sachkompetenz angeht.

[Gemikro]

Hallo RaspII,

ich bin auch grad dabei die Kopp Sender zu entschlüsseln.
Allerdings hab ich den Logger noch nicht fertig.
Aus Deiner Excel Datei sehe ich aber heraus dass die Pakete alle gleich sind.
Wenn Du die Daten nicht als HEX Werte sondern als Binär-Wurst aufschreibst dann wird aus AA z.b. um ein Bit verschoben 55.
Aus AA 54 07 C8 F9 9A B0 ... wird dann
10101010010101000000011111001000111110011001101010110000
und aus A9 50 1F 23 E6 6A C3 ...
10101001010100000001111100100011111001100110101011000011

was um zwei Bit nach rechts verschoben die gleiche Bitfolge ergibt wie oben:
10101010010101000000011111001000111110011001101010110000
__10101001010100000001111100100011111001100110101011000011 
auch bei 95 01 F2 3E 66 AC ...
__________1001010100011111001000111110011001101010110000110011001111000000 

d.h. das gesendete Bitmuster ist immer gleich. Zu Beginn 01010101... dann kommen irgenwann 7 Nullen und dann die gleichen Daten.
Sinnvoller zur aufzeichnung wäre d.h. die Bitfolge und triggern auf das Ende des 10101010 Musters.

Wenn ich den Logger fertig habe werd ich mal meine diversen Kopp Geräte aufzeichnen und versuchen die Funktion der einzelnen Bits herauszulesen.

lg Max

[RaspII]

Hi Max,
du bist gut !
Mir ist das so noch nicht aufgefallen, obwohl ich mir das ganze auch binär angeschaut hatte.
Ich habe Deine Überlegungen aber noch nicht komplett verstanden, warum denkst Du, dass auch die 95 01 F2 3E 66 AC ...
die gleiche binärfolge liefert, dort ist doch zumindest die von mir Fett unterlegte Bitfolge unterschiedlich (trotz Verschiebung!)
Kannst Du mir da auf die Sprünge helfen?

Zitat:
was um zwei Bit nach rechts verschoben die gleiche Bitfolge ergibt wie oben:
10101010010101000000011111001000111110011001101010110000
__10101001010100000001111100100011111001100110101011000011
auch bei 95 01 F2 3E 66 AC ...
_________1001010100011111001000111110011001101010110000110011001111000000 
Zitat Ende

Hab das nochmal weitergesponnen:
Nimmt man die erste Zeile: AA 54 07 C8 F9 9A B0 CC 0F als Binärwert
101010100101010000000111110010001111100110011010101100001100110000001111      und stellt die 95 01 F2 3E 66 AC 33 03 C0 ..  incl. vorangehender AA's (=1010 er Folgen) darunter dar:
10101010010101xxxx000111110010001111100110011010101100001100110000001111000000
ist die Zeichenfolge wieder bis auf die 4 fetten x wieder 54 07 C8 F9 9A B0 CC.. , die weiteren Binärzahlen müsste man erst noch verifizieren.
So richtig passt das alles noch nicht zusammen, auch wenn ich glaube Du bist auf der richtigen Spur.


Gruß
Claus


Nachtrag:
Habe glaub ich den Fehler gefunden: 9501 ist nicht wie von Dir geschrieben =
100101010001  binär  sondern
1001010100000001 binär,
damit sind die 4 fetten x durch  0000  zu ersetzen und alles ist wieder logisch richtig.

Jetzt muss ich nur noch klären ob das Sync Pattern am Anfang 55 oder AA ist.
Da ich bei AA eine korrekte Checksumme bekomme gehe ich mal von AA aus.

Ich schreibe bei Gelegenheit mal meine Software um und triggere auf die Zeichenfolge  aa 54, warte danach auf einen Block mit definierter Länge und triggere wieder auf aa 54.
Wenn möglich schreibe ich auch mal die Zeitstempel mit, vielleicht sind dadurch ja Sendepausen etc. reproduzierbar oder Störungen (Sender macht Pause) besser zu identifizieren.
Danach sollte eigentlich alles reproduzierbar sein (hoffentlich).
Wenn das klappt, werde ich versuchen die Daten korrekt zu senden und schau mal ob das Kopp Modul wie erwartet reagiert.

Das kann allerdings etwas dauern (habe kaum Zeit).

dank Dir nochmal für die Hilfe, das hat mich richtig weitergebracht.

Gruß
Claus

[Gemikro]

Hi RaspII,

war gestern schon etwas spät ich hab das auf Dienstreise am Schleppi im Hotel getippt
Da können sich schon ein paar Fehler einschleichen.

Ich habe daheim ein paar Handsteuerungen herumliegen (822302025, 811402020, 811407025) und mehrere Empänger (Rolladen, Einzelempfänger, schaltbare Steckdosen etc.).
Sobald ich meinen 868Mhz Empfänger hab logg ich da mal mit.

Mir kommt so vor als ob der große Handsender etwas anders funktioniert als der kleine.
Jedenfalls verhalten sich die Rollladen anders mit dem kleinen (reagieren langsamer).
Ich bin auch gerade dabei die Rollladen Schalter alle umzubauen, da sind nach 7 Jahren Betrieb die Netzteil Kondis defekt und manche von den Schaltern reagieren nur mehr schlecht. Die Ersatzteile gibts um ein paar Cent beim Farnell und danach gehen die Schalter wieder wie neu.

Hab mir dabei auch die verbauten Chips ansehen.
In den Rollladen Empfänger sitzt ein CC1100 (TI 868 Transceiver) so wie am CUL (dort ist´s halt ein CC1101) und ein echter Atmel (ATmega48V).
In allen Sendern sitzt immer ein CC1150 (TI 868MHz Transmitter) und ein scheinbar chinesischer Nachbau für den Atmel (T2313V 10MUCL).

Werd mal schauen ob man die Atmels auslesen kann, die SPI Pins sind auf Testpads herausgeführt 

lg Max

[RaspII]

Hi Max,
so gefält mir das.
Die Info mit den Sender IC's hatte ich auch schon, die Info bzgl. Empfänger IC's ist für mich neu und wertvoll (habe meine 3 Empfänger im Schaltschrank verbaut und keine Lust den zu zerlegen )
Ich benutzte für meine Experimente das RFM12b Modul mit einem Si4420/Si4421 868MHz IC von Silicon Labs.
Erst durch Deine Info wurde mir gestern bewusst, dass der Baustein die einzelnen Bytes nicht über Start/Stopp Bits synchronisiert sondern einfach jeweils n mal 8 Bits sendet und der Empfänger die Synchronisation über bestimmte bekannte Pattern durchführt. Genau hier habe ich ein Problem mit dem RFM12B Modul im Empfangsmode.
Ich kann ein maximal 2 Byte großes Pattern festlegen. Ein Byte davon ist frei definierbar, das 2te Byte liegt fest auf "2D". Damit kann ich aber kein zu den Kopp Modulen passendes 2 Byte Synchron Pattern definieren, in SW möchte ich das nicht nachbilden. Ein ein Byte Synchron Pattern liefert mir zu viele falsche Trigger (ca. alle sec. ein Ereignis ohne das der Sender überhaupt bedient wird).

Habe mir eben das Datenblatt zum CC1101 grob angeschaut.
Dieser Baustein kann tatsächlich ein Sync Pattern von 16Bit frei konfigurieren, damit könnte man z.B. auf AA 54 synchronisieren und alles wäre gut
Allerdings ist der Baustein so komplex, dass man vermutlich einen Monat braucht um zu verstehen wie er zu konfigurieren ist , da ist der Umgang mit dem  RFM12b Modul deutlich einfacher.

Die gute Nachricht:
Eigentlich habe ich ja schon die meisten  Info's die ich brauche um die korrekten Botschaften zu senden.
(Der Empfänger ist ja nur ein Hilfskonstrukt um rauszubekommen was die Sender so treiben).
Ich muss jetzt "nur" noch ermitteln wie oft die Sender die Blöcke wiederholen und wie groß die Pausen zwischen den Blöcken sind, danach kann ich mal auf "Sendung" gehen.
Notfalls kann ich den Empfänger nochmal in Betrieb nehmen und auf 54 Synchronisieren, falsche Schrott-Botschaften muss ich dann per SW aussortieren .
Ich melde mich wieder, spätestens sobald ich meinem Schaltschrank per Raspberry Pi steuern kann . (Könnte aber einige Wochen dauern)

Was Dir evt. weiterhilft:
Im Meinem Excel Sheet Blatt "Block1" habe ich ja schon aufgeführt was mein großer Handsender (811402) sowie mein kleiner Handsender (8114.07) an Kommandos sendet.
Vor allem die Daten zum großen Handsender sind sehr aufschlussreich (kurzer Tastendruck). Falls Du schon die Möglichkeit zum senden hast kannst Du ja mal Loslegen und schauen ob es funktioniert.
Evt. muss Du nach der vermeindlichen Checksumme noch die Nullen+den Rest mitsenden (das ist in Sheet "Taste dauergedrückt" besser herausgearbeitet).

Welche IC's hast Du eigentlich bzw. welche wirst Du Dir besorgen?
Ach noch was, wozu willst Du eigentlich die Atmels auslesen? Um die Kommunikation zum HF Modul zu belauschen (wird ohne gute Meßgeräte & Protokoll Interpreter nicht einfach sein, Du wirst doch nicht die Bits von Hand zählen wollen ?)


Gruß
Claus

[Gemikro]

Hallo RsapII,

Bits per Hand zählen tu ich nur auf Dienstreise wenn ich am Abend nichts besseres zu tun hab
Ich hab einige Atmels + ISP, Arduinos, Raspberry Pi, Beaglebone etc. herumliegen irgendwas wird sich da schon finden mit dem man senden und empfangen kann.
Die Receiver und Transmitter bekomme ich erst nächste Woche, muß da auf eine Sammelbestellung warten.
Ich hab auch ein RFM12b Modul bestellt.

In der Firmware für den CUL müsste ja ein Modul für den CC1101 dabei sein oder.
Das müssten wir doch nicht neu programmieren ?

Was ich noch interessant finde ist dass die Empfänger einen Transceiver haben und somit senden können. Womöglich wiederholen die Dinger die Meldungen die sie empfangen und nicht der Sender

Grüße
Max

[RaspII]

Hi nochmal,
CUL sagt mir nix, musst Du mir erklären. (Nachtrag: hab grad gegoogled und verstanden)
Für den Raspberry Pi und das RFM12b Modul habe ich Sende und Empfangssoftware verfügbar die den Kopp Sender prinzipiell empfangen kann.
Die Empfangssoftware ist zwar noch bastelei, damit konnte ich aber die Daten für's Excel Sheet empfangen.

Auch senden müsste tun, allerdings reagiert mein Kopp Schaltmodul noch nicht darauf (könnte aber auch einfach ein Reichweitenproblem sein, die Schaltmodule sind im Sicherungsschrank und mein Raspberry Pi ist zwei Stockwerke entfernt).


Nachdem ich mir gestern das Datenblatt vom CC1101 angeschaut habe hoffe ich, dass wir mit dem RFM12b Modul auskommen, der ist völlig simpel zu programmieren.
Alles andere (SPI Kommunikation....) ist für den Raspberry Pi verfügbar, ich kann Dir bei Bedarf mal zusammenstellen welche Schritte ich unternommen habe bis das RFM12b Module funktioniert hat.
(wollte das sowieso noch dokumentieren)

Ich bin mir sehr sicher, dass der Sender die Daten wiederholt. Drückt man die Taste nur ein mal, kommt immer der gleiche Block. Beim nächsten Druck wird das Zählerbyte incrementiert.
Bei einem langen Druck wird zuerst ein um 80hex erhöhter Tastencode gesendet, beim Loslassen der Taste kommt als Tastencode 7F, das macht alles richtig Sinn.
Ich hätte auch erwartet, dass der Sender den Block wiederholt, Man muss ja mit einer gestörten Übertragungstrecke rechnen.

Würde mich darüber freuen, wenn Du Dir das RFM12B Modul auch auf den Raspberry Pi klemmst, ich vermute mal dass wir schneller unterwegs sind wenn wir gemeinsam an einer Lösung arbeiten.
Hab noch ein Bild von meinem Aufbau angehängt.

Gruß
Claus

[RaspII]

Hallo Max,
ich bin am Verzweifeln.
Ich habe am Wochenende meine Software umgebaut, Zeitstempel hinzugefügt
und mal auf das erste Byte gesynct, das immer konstant ist (5A).

Über die Zeitpattern habe ich rausbekommen, dass sobald die X11 Oberfläche, Dateimanager, Leafpad etc. auf dem RPi läuft es mit der echtzeit nicht mehr weit her ist.
8 Bit benötigen zum Empfangen ca. 1,67 ms, ich hatte Jitter bis zu 30ms (d.h. mir gingen einige Bytes flöten).
Gehe ich nicht über X11 auf den RPi sonder mit einem einfachen Terminal, empfange ich die Bytes mit einem Jitter von max. ca. 300µsec, das erklärt sich über das Fifo.
Somit ist klar, warum ich manchmal völlig unerklärbare Ergebnisse hatte. -> Problem erkannt / gebannt 

Aber jetzt kommts.
Schaut man sich die plausiblen Botschaften im Excel Sheet an, ist das erste plausible Byte immer 54.
Wenn ich auf 0x54 synchronisiere bekomme ich immer falsche Botschaften. Ich konnte mir das nicht erklären, schaut mal sich aber den Bitstream wieder an (Du siehst ich bin lernfähig), sieht man folgendes:
Ich weiss ja schon, dass ca. 17 Bytes Präambel mit 0xAA ankommen.
D.h. die erste gültige Botschaft fängt folgendermaßen an:
....AA5407...
als Bitstream:
101010100101010000000111

Im Detail:
   A  |   A  |  5   |  4   |  0  |  7
101010100101010000000111

Das Sync Byte 54 kann man in diesem Stream auch so finden:
|  5   |  4   |  A   |  8  |..........
101010100101010000000111

und da diese 54 immer vor der erwarteten 54 kommt wird automatisch jedes mal falsch gesynct. ! 
Synce ich auf die 07 klappt es prinzipiell. Es kommen danach 8-10 korrekte Blöcke an, die Bitverschiebungen wie oben beschrieben (z.b. 95 statt 54) gibt es nicht mehr.
Allerdings kommt es ohne Signal immer mal zu Störsyncronisationen, da ich per SW nichts mehr zusätzlich filtern kann (das nächste Byte ist senderspezifisch)

Jetzt hilft nur noch eines (fällt mir gerade ein, es hilft wenn man schreibt).
Ich synce auf 07, lese den restlich erwarteten Block komplett ein und prüfe die Checksumme.
Ist die Checksumme ok -> Block wird verwertet
Ist die Checksumme nicht ok werfe ich den Block weg.
(und ich hoffe, dass es keinen Kopp Befehl gibt der eine Länge <> 07 hat, die 07 ist das Längenbyte)
Ich melde mich falls ich das heute noch schaffe

Gruß
Claus

Nachtrag:
Ich Synce jetzt auf 0x07 und prüfe die gültigen Blöcke anhand der Checksumme.
Ergebnis: funktioniert einwandfrei.
Bei jedem "kurzen" Tastendruck werden 13 identische Botschaften gesendet.
Drücke ich die Taste 2x hintereinander erhöht sich der "Tastendruckzähler" um 1
Bei lange Tastendrücken werden auch 13 identsiche Botschaften gesendet (Tastaturcode wie bei kurzem Druck +0x80)

Habe das mit 2 Handsendern (mehr hab ich nicht) und unterschiedlichen Tastendrücken getestet,  es funktioniert jedes Mal und problemlos.

Details zu einer Aufzeichnungssequenz siehe angehängtes Excel Sheet, Tab: 17.3.2014

So, demnächst mache ich mich ans senden, incl. Präambel von 17x AA,  Checksumme etc.
Mir ist nur noch nicht klar, ob die fünf bis sechs 0x00 Bytes die in den alten Aufzeichnungen nach einem gesendeten Block kommen aktiv gesendet werden müssen
oder ob die Bits nur als "0" gelesen werden weil nach einem starken Sendesignal plötzlich kein Signal mehr kommt (das kann man nur direkt am Sender nachmessen)

Gruß
Claus

[Gemikro]

Hallo Claus,

hatte leider in den letzten Tagen keine Zeit für die Bastelei
Ich werd mir Deine Datei mal durchsehen, Du hast da ja schon einiges zusammegetragen !
Am Wochenende hab ich hoffentlich wieder Zeit.

Inzwischen sind auch meine Bauteile eingetroffen und ich werd mal einen Arduino ProMini mit dem RFM12B zusammenschalten.
Es gibt da für den Arduino auch schon eine Lib (JeeLib) die den Transponder anspricht, damit sollte es eigentlich einfach sein einen Logger zu programmieren.
Sobald ich das habe lese ich meine Sender aus und dann können wir die Daten vergleichen.

Ich denke auch das die angehängten Nullen nur von der Software kommen, wenn nötig kann ich da eventuell mal mit dem Oszi nachsehen.

lg Max

[RaspII]

Hallo Max,
ich habs geschafft. Kann jetzt über meinen Raspberry Pi und das RFM12b Modul meine Kopp Empfänger schalten.
Ich war die letzten zwei Tage am verzweifeln, konnte keine Fehler mehr finden und es tat trotdem nicht.

Der Schlüssel zum Erfolg war, dass ich den FSK Modulationsparameter auf maximalwert gesetzt hatte, man muss den aber an die 4,8kBaud anpassen (45 kHz).
Nachdem ich jetzt mein TX CONFIG Register von 0x98F0 auf 0x9820 geändert habe funktioniert das ganze einwandfrei (über 2 Stockwerke, Empfänger sitzen im Schaltschrank).

So, jetzt muss ich ich nur noch die Details angehen, d.h. mir den Blockzähler irgendwie merken, damit beim nächsten Programmaufruf nicht wieder von vorne begonnen wird, und zwischen langen und kurzen Tastendrücken unterscheiden.

Falls Du es Dir noch anders überlegst und den Raspberry Pi benutzt, kann ich noch zusammenschreiben wie man das ganze zum Laufen bekommt.

Gruß
Claus

[Gemikro]

Hallo Claus,

Ich habe inzwischen erst einmal einige meiner Rollladen Empfänger ausgebaut und repariert.
Bei meinem kleinen Handsender habe ich auch gefunden warum der sich so anders verhält als der große.
Am Print beim Antennenausgang war ein SMD Kondensator nur einseitig angelötet, der dürfte beim Reflow Löten aufgestanden sein.
Damit war dann manchmal Kontakt, manchmal halt nicht ...
Neu Löten hat dann die Reichweite des Senders gleich deutlich erhöht.

Die Atmels in den Dingern lassen sich wie erwartet nicht auslesen, die Lock Bits sind gesetzt.

Ich sitze gerade vor meinem Arduino Pro Mini und versuche mich an der Kommunikation mit dem RFM12b.
Derzeit habe ich aber noch Probleme mit der Konfiguration die Du ja schon gelöst hast.
Wär nett wenn Du mir sendest was Du schon programmiert hast.
Das sollte sich einfach auf den Arduino übertragen lassen.

Was nimmst Du den übrigens als Antenne ?

Grüsse,
Max

[RaspII]

Hi nochmal,
als Antenne habe ich einen 8,6 cm langen Draht verwendet (Lambda viertel, wenn ich richtig gerechnet habe).
Meine Sende- / Empfangsroutine habe ich mal angehängt, das ist leider noch "Spagetticode", zu mehr hat's bisher nicht gereicht 
Ich hatte hierfür übrigens eine Vorlage von
http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/
benutzt. Der Author hatte damit Wettersensoren ausgelesen. Das hat mir sehr geholfen die ersten Schritte zu machen.

Hab inzwischen wieder einen Rückschlag erlitten, nach ausführlichen Tests habe ich bemerkt, dass die Funkschalter nicht jedes mal schalten wenn ich sende,
auch nicht wenn ich den Rapsberry Pi mit Sender direkt neben den Schaltschrank stelle (scheint dem Zufallsprinzip zu folgen). 
Das bekomme ich früher oder später auch noch hin.

Na dann viel Spaß beim Löten.
Claus

!!!!!  Neu  !!!!!   7.4.2014: Habe die aktuellste Version meiner RFM12b Module anghängt und die alte Version gelöscht

[Gemikro]

Hallo Claus,

danke für die Datei, ich hab leider diese Woche wenig Zeit, hoffentlich wieder nächstes Wochenende.

Hast Du bei Deinen Schaltern schon mal die Kondensatoren kontrolliert ?
Die sind bei praktisch allen von meinen Rollladenschaltern kaputt, ich habe gleich einen Vorrat bestellt und inzwischen mehrere Schalter repariert.
Solange die Kondis nicht getauscht sind habe ich das gleiche Problem wie Du. Manchmal reagieren die Empfänger dann gar nicht mehr und man muß den Strom für ein paar Sekunden abschalten und dann gehts wieder einige Zeit.
Die eingebauten Kondis (Carli X2 MPX40, 250V; waren bisher in allen Empfängern gleich), sind eigentlich laut Hersteller nicht für diese Anwendung geeignet weil sie die Kapazität auf Dauer nicht halten können und dann das Kondensatornetzteil keine Leistung mehr bringt.
Bessere sind leider nicht in der 15mm Bauform zu bekommen aber die die ich bestellt habe sollten doch etwas länger halten (Epcos MKP X2 B32922, 305V).

[RaspII]

Hi,
ich denke nicht, dass es an den Kondi's liegt, mit den Handsendern funktioniert alles einwandfrei.
(trotzdem Danke für den Tipp, werde den früher/später brauchen können).

Ich werde noch nachprüfen ob ich bei irgendwelchen Frequenzen / Bitraten nicht ganz die Mitte getroffen habe (das Kopp auf 868,3 Mhz Mittenfrequenz arbeitet habe ich z.B. aus irgendwelchen Foren, vielleicht sind diese Info's nicht völlständig.)

Bis demnächst

[RaspII]

Hi Max,
habe mal die Bitrate nach oben korrigier, jetzt klappts etwas besser aber immer noch nicht zuverlässig (vielleicht sollte ich die Empfänger direkt auf das RFM12b Modul anlernen,bisher emuliere ich nur einen meiner Sender).

Habe jetzt den FHEM Server bei mir installiert und hab es letztendlich durch ausprobieren  und stöbern in den Foren  tatsächlich geschafft meine Software zu triggern und die Kopp Schalter zu bedienen. Das Hauptproblem war, dass man FHEM die Rechte geben muss externe Software vom "/home/pi/..." Laufwerk zu starten. Wie das gemacht wird und welche Modifikation ich in der Datei fhem.cfg durchgeführt hab ist im Anhang "MyInfoFHEM.txt" zu sehen. Die Datei MyFHEM.jpg zeigt wie das in etwa auf dem Handy aussieht (Screenshot ist vom PC).
FHEM ist unglaublich mächtig, das Problem ist einfach wenn man selbst kaum Erfahrung mit der Bash Shell, Perl und C hat.
(Habe meine Erfahrungen hauptsächlich in der Assembler Programmierung gemacht). Dann dauerts halt etwas länger.

Die Software für den RFM12b via Raspberry Pi habe ich noch umgebaut, damit ich Parameter übergeben kann, als ersten Schritt mal den "Tastencode" des Senders, die Dateien kann ich bei Bedarf noch anhängen (ansonsten mach ich das wenn ich fertig bin).
Der nächste Schritt ist für mich jetzt den "langen Tastendruck" incl. "Taste loslassen nach n msec", damit wären dann die komplette Funktionalität eines Kopp Senders emulierbar.

An dieser Stelle auch noch einen großen Lob an die FHEM Entwickler. FHEM ist wirklich Klasse.

Wie stehts bei Dir, hast Du Fortschritte gemacht?

Gruß
Claus

[Gemikro]

Hallo Claus,

ich steck irgenwie fest.
Ich kann jetzt zwar mit dem RFM12B reden aber irgenwie kann ich nicht so richtig auf die Pakete triggern.
Ich habe erst eine halbe Meldung abgefangen, die beginnt wie bei Dir mit 17 x aa und dann
54 07 7f 01 6f 10 cc 0f 03 ff ff und so weiter aber irgendwie komme ich fast nie bis zur Checksum und ab so 10 Bytes kommt meistens nur noch Müll.

Ich hab eine nette Demo für den Arduino und den RFM12B gefunden mit dem man den ganzen Empfangsbereich scannen kann und so die Sendefrequenzen und den Hintergrund sehen kann:
http://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B

Bei mir funken in der Umgebung jede Menge Geräte durchgehend auf verschiedenen Kanälen.
Was ich dabei gefunden habe ist dass jeder meiner Sender auf einer leicht unterschiedlichen Frequenz sendet.
Mein zweifach Wandtaster sendet auf 868.50 und wenn man dem nRFmon trauen kann mit einer FSK Shift von 240kHz. Der einfach Wandtaster sendet auf 868.35

Ich habe versucht mit Deinen Einstellungen zu Arbeiten aber da bekomme ich irgendwie keinen Empfang.
Werd´s noch weiter versuchen...

Grüsse,
Max

[RaspII]

Hi Max,
hast Du eine Möglichkeit ein RFM12b Modul direkt auf den RaspberryPi zu löten?

Dann könnten wir mit der exakt identischen Software arbeiten.
Meine Empfangsroutine liest meine beiden Sender völlig problemlos ein, einzige Bedingung ist, dass der RPi sonst nichts zu tun hat. Je nach Rechenleistung Deines µC's könnte aber schon die Ausgabe der Daten an ein Terminal etc. den µC zu stark ausbremsen.
Deshalb solltest Du immer die Zeitstempel mitlesen und verifizieren ob der Abstand der Datenbytes bei ca, 1,6ms liegt (darf Jittern, wegen dem Fifo, im Mittel muss der Wert allerdings stimmen.
Zeiten größer 3msec deuten darauf hin, dass Dir Daten verloren gingen. 

Meine Routinen sind so geschrieben, dass Daten gelesen/geschrieben werden wenn der Interrupt Pin aktiv ist.
Sind andere Interrupt Quellen aktiv, könnte das allerdings dazu führen, dass das Fifo gelesen wird bevor neue Daten anliegen (nur so eine Idee). Bin aber schon dran, auch noch den Inhalt des Statusregisters zu berücksichtigen, dann sollte es dieses Problem nicht mehr geben.

Wünsch Dir viel erfolg bei der Suche, ich experimentiere noch mit ein paar Paremeter (Sendeteil) rum, damit die Schalter endlich auf jeden Befehl reagieren.

Gruß
Claus

[RaspII]

Hi,
wegen Deines Problems:
es könnte durch eine fehlerhafte Konfiguration der "Receiver Control Command"-  oder "Data Filter Command" Register kommen.
Sind diese falsch konfiguriert, kann die Clock recovery schiefgehen (nur so eine Idee).

Den "langen Tastendruck" hab ich jetzt auch programmiert -> funktioniert!
Ich probier das ganze jetzt noch mit kleinen Frequenzoffsets aus, vielleich bekomme ich das System dann noch stabiler hin.
(Hab im Datenblatt gelesen, dass der RFM12b auch mit schlechteren Quarzen auskommt, da die AFC im Empfangsteil das ausgleichen kann.
Vielleicht ist der Kopp Empfänger nicht so gut drauf)

Gruß
Claus

[RaspII]

Hallo zusammen,
habe inzwischen meine SW auf ein CCD (CUL kompatibel, wird anstelle des CULs auf dem RaspberryPi verbaut) portiert.
Bin noch nicht zu 100% fertig, kann aber schon "kurze Tastendrücke" senden.
Wenn das Modul komplett fertig und getestet ist, könnte man es auch auf dem CUL freischalten, ich brauche dann allerdings Support fürs Testen, da ich keinen CUL besitze.

Gruß
Claus

[Andreas_]

Also ich hab ne Fritzbox 7390 und einen Cul-Stick sowie diese Kopp Rolladensteuerungen. Ich habe auch noch einen Kopp- Rolladenempfänger übrig. Damit könnte ich experimentieren.

Ich biete mich somit an!

[RaspII]

Hi,
ich bin grad an der Lohnsteuer und komme die nächsten Tage/Wochen eher nicht dazu.
Ich melde mich wieder sobald ich was habe.

Gruß
Claus

[RaspII]

Hi,
anbei meine neuesten Erkenntnisse über das FreeControl Protokoll.
Das erste Sheet enthält die relevante Übersicht

Gruß
Claus

[BloederRegistrierungsNepp]

Hallo zusammen!

Ich bin gerade dabei, zusammen mit dem RFM12B, einen ähnlichen Sender aufzubauen. Aufgrund des Registerungs-nepps kann man hier ohne Account keine Dateianhänge herunterladen, weswegen ich nun extra einen Account erstellen musste *grml*

Vielen Dank an diejenigen, die hier fleißig recherchieren. Ich habe mir Eure Erkenntnisse runter geladen und werde meine Ergebnisse an offenerer Stelle veröffentlichen 

Vielleicht liest der Betreiber des Forums ja mit und nimmt meine Kritik zu Herzen...

[RaspII]

Hi,
ich bin inzwischen komplett weg vom RFM12b Modul und auf den CUL umgestiegen.
Der CUL entkoppelt die "Echtzeit" vom Raspberry Pi da hier ein eigener µC verbaut ist.

Hintergrund:
mit dem RFM12b Modul habe ich immer mal wieder das Problem gehabt, dass die Aktoren nicht reagierthaben.
Irgendwann ist mir dann aufgefallen, dass dies immer geschieht wenn ich z.B. auch die X11 Oberfläche auf dem Raspberry Pi aktiv hatte oder andere rechenzeitintensive Anwendungen liefen.

Per CUL kann ich inzwischen stabil Kommando's senden, eine FHEM Implementierung hierzu gibt es auch schon (Dimmen, Schalten klappt, Rolladensteuerung fehlt noch).

Zurzeit bin ich dabei den Empfangsmode zu implementieren, per Terminalprogramm und dem CUL kann man die Rohdaten bereites sehen, die FHEM Implementierung fehlt noch.

Gruß
RaspII

P.S.:
Ich finde es eigentlich ganz ok, dass man sich hier registrieren muss bevor man richtig Info's abgreifen und auch mitarbeiten kann.
Das bringt etwas Ordnung ins System (ja, und man muss sich ein Passwort mehr merken, aber dafür gibt es ja KeePass).

[RaspII]

Hallo,
wollte in diesem Thread noch Bescheid geben:
Der Empfangsmode ist jetzt implementiert.
Einfach die culfw und FHEM updaten, dann sollte es funktionieren.

Ich habe auch mit einem Wikieintrag angefangen, siehe:
http://www.fhemwiki.de/wiki/Kopp_Allgemein

Gruß RASPII