Modulentwicklung - mit CUL Kommunizieren

[litronics]

Hallo Zusammen,

ich glaube dass das Thema im falschen Bereich ist - aber bei den Entwicklern darf ich leider keine neuen Threads starten.

Momentan bin ich dabei mich in das Modulsystem einzuarbeiten und möchte ein eigenes Modul für das Conrad RSL Protokoll schreiben. Alles in allem hab ich mein Modul insofern fertig, dass es ON und OFF so verarbeitet und anzeigt wie ich das haben möchte.

Jetzt bin ich in dem Punkt wo ich die Daten an die Schalter senden müsste und das sollte natürlich über den CUL gehen. Ich habe schon versucht das IT Modul (das sendet ja auf 433MHz Befehle) zu lesen aber da scheitere ich irgendwie an meinen noch begrenzten Programmierverständnis.

Könnte mir vielleicht jemand helfen, wie ich mit IOWrite eine einfache Bitfolge (Start und Stopp-Bits würde ich direkt mit eincodieren) über den CUL auf 433MHz verschicke?

Herzlichen Dank!

[KölnSolar]

so einfach wird das nicht, es sei denn, das Protokoll wäre IT-konform. Aber dann könntest Du ja das IT-Modul nehmen.
Es ist quasi 3-stufig: firmware des CUL(ich empfehle aculfw) - 00_CUL - 10_IT
Nur senden wäre alternativ vielleicht über das G-command möglich.
Grüße Markus

[andies]

Signalduino erlaubt so etwas, glaube ich. Ich habe meine Gartentoröffnung so gesteuert.


<p style="font-size:small;"> Gesendet vom iPhone mit Tapatalk Pro</p>

[litronics]

Danke für die schnelle Antwort!

Leider nein
Conrad hat in der eigenen RSL Umsetzung die Bitreihenfolge im Datagramm einfach mal vertauscht 
Für mich persönlich reicht senden vollkommen - hauptsache ich kann die Schalter definieren und die Daten senden.

Die Modul reihenfolge war mir soweit klar und wenn ich die Anleitung verstanden habe, dann sollte ich mit IOWrite die write Funktion eines anderen Moduls aufrufen können.

Was ich aber noch nicht verstanden habe ist wie ich die culfw-referenz mit dem IOWrite zusammenbekomme. Verstehe ich das so richtig wenn ich den G-Befehl verwenden möchte..

Code Auswählen Erweitern

IOWrite($hash, "G", "ssNnprHHLLhhllDDDD");

wobei

• $hash - der CUL ist
• "G" der Befehl und
• ssNnprHHLLhhllDDDD die Daten als HEX Wert sind
  

Dann müsste ich nur noch herausfinden wie ich den CUL temporär auf 433MHz unstellen kann - am Besten ohne den Wert in's EEPROM zu schreiben. Soll ja direkt nach dem Senden wieder zurück auf den Ursprungswert.

[litronics]

Signalduino erlaubt so etwas, glaube ich. Ich habe meine Gartentoröffnung so gesteuert.

Theoretisch - wobei bei Conrad RSL aktuell steht, dass es auch nicht geht

Für mich aber eigentlich uninteressant - ich brauch zwingend FS20 da ich so ziemlich alles in FS20 realisiert habe und das kann Signalduino laut Wiki nicht.
Ergo muss es mit einem CUL (mit CULFW oder A-CULFW) funktionieren.

[andies]

Ich meinte: raw senden geht. Aber das nützt Dir, wenn ich das richtig verstehe, nix.

[KölnSolar]

Dann müsste ich nur noch herausfinden wie ich den CUL temporär auf 433MHz unstellen kann - am Besten ohne den Wert in's EEPROM zu schreiben. Soll ja direkt nach dem Senden wieder zurück auf den Ursprungswert.

Ei, nen 868er...
Umschalten kannst Du mit set DeinCUL freq 433.92
zurück für FS20 868.35
schreibt aber meines Wissens ins EEPROM u. macht ihn auf Dauer kaputt 

Verstehe ich das so richtig wenn ich den G-Befehl verwenden möchte..

Ich denke nicht. Ist aber auch der falsche Ansatz. Erst einmal gilt es den raw-G-Befehl zu definieren und testen. Guck mal hier, da haben wir es kürzlich gemacht.
Absetzen kannst Du dann über Dummy, Routine in der myUtils ......

[Amenophis86]

ich glaube dass das Thema im falschen Bereich ist - aber bei den Entwicklern darf ich leider keine neuen Threads starten.

Du kannst Schreibrechte über dein Profil beantragen, wenn du dort schreiben möchtest. Nur mal so als Hinweis neben der Diskussion.

[betateilchen]

möchte ein eigenes Modul für das Conrad RSL Protokoll schreiben.
...
aber da scheitere ich irgendwie an meinen noch begrenzten Programmierverständnis.

Dann dreh die Reihenfolge einfach mal um. Lerne und verstehe die Programmiersprache und fang bitte dann erst an, ein Modul zu bauen.

[Ralf9]

Theoretisch - wobei bei Conrad RSL aktuell steht, dass es auch nicht geht

Dies ist nicht mehr aktuell, inzwischen funktioniert das Conrad RSL mit der dev-Version vom Signalduino

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Du brauchst das Modul nicht komplett neu entwickeln, für den Signalduino gibt es ein fertiges und funktionierendes Modul
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r33/FHEM/14_SD_RSL.pm

Gruß Ralf

[litronics]

Dann dreh die Reihenfolge einfach mal um. Lerne und verstehe die Programmiersprache und fang bitte dann erst an, ein Modul zu bauen.

Danke für den netten Kommentar - war seh konstruktiv!

Perl verstehe ich recht gut aber vielleicht habe ich mich falsch ausgedrückt - die ganzen Abehängigkeiten innerhalb der Module und wie welches Modul angesprochen werden möchte ist dann auf Anhieb doch etwas viel. Auch wenn man grundsätzlich Perl versteht.

[litronics]

Dies ist nicht mehr aktuell, inzwischen funktioniert das Conrad RSL mit der dev-Version vom Signalduino

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Du brauchst das Modul nicht komplett neu entwickeln, für den Signalduino gibt es ein fertiges und funktionierendes Modul
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r33/FHEM/14_SD_RSL.pm

Gruß Ralf

Danke für den Tipp Ralf!

Ich habe just im Moment eh meinen Ansatz überden Haufen geworfen und hab mir einen zweiten CUL bestellt. Den Flashe ich dann für 433MHz und kann dann beide Fequenzen gleichzeitig.

Signalduino werde ich gleich mal testen...

[litronics]

Sodalle - jetzt hab ich Signalduino drauf und versucht den Schalter anzulernen - das klappt schon mal nicht

Dann hab ich mir einen RSL-Schalter definiert und versucht den Schalter selbst anzulernen - das klapt auch nicht

Parallel habe ich mir mit einem Arduino-Mega und RC-Switch einen kleinen Sniffer gebaut um unabhängig vom Log zu sehen was los ist.

Ein paar weitere Erkenntnisse habe ich durch den Sniffer auch noch erhalten.

1. Wenn ich einen in FHEM definierten RSL Schalter schalte, dann bekomme ich folgenden Einrag:

Code Auswählen Erweitern

Decimal: 258 (9Bit) Binary: 100000010 Tri-State: not applicable PulseLength: 616 microseconds Protocol: 2
Raw data: 6168,1100,612,24,364,24,20,16,16,28,16,32,20,24,28,28,628,1348,48,

2.Wenn ich die Fernbedienung betätige bekomme ich folgenden Eintrag:

Code Auswählen Erweitern

Decimal: 2172188070 (32Bit) Binary: 10000001011110001111010110100110 Tri-State: not applicable PulseLength: 636 microseconds Protocol: 2
Raw data: 24124,16,184,32,16,20,24,112,20,88,16,28,20,52,156,20,260,28,16,24,68,1048,1316,44,44,56,172,16,20,28,16,16,1496,16,116,20,588,884,24,52,1116,116,32,28,80,24,16,20,48,1056,32,96,1428,20,144,24,24,16,24,44,16,24,16,20,28,

Ergo scheint das implementierte Conrad RSL nicht mit dem RSL, das meine Conrad-Schalter verwenden kompatibel zu sein.

Mittlerweile habe ich aber zwei Befehle gefunden welche annähernd das gleiche Ergebnis im Sniffer produzieren wie die Fernbedienung:

Code Auswählen Erweitern

ein --> set Sduino sendMsg P1#10110110011110001111010110100110#R6
aus --> set Sduino sendMsg P1#10111110011110001111010110100110#R6

Das Ergebnis im Sniffer ist folgendes:

Code Auswählen Erweitern

Decimal: 3061380518 (32Bit) Binary: 10110110011110001111010110100110 Tri-State: not applicable PulseLength: 639 microseconds Protocol: 2
Raw data: 6372,1092,832,376,1380,1132,756,1112,800,424,1472,1040,744,1112,800,416,528,20,876,408,1376,1136,768,1112,808,1072,784,1088,752,456,1404,388,1408,424,1420,1092,796,1096,812,1064,748,1120,756,464,1412,1100,832,372,1380,1120,796,424,1380,1120,784,432,1436,400,1424,1088,752,1120,784,448,496,

Decimal: 3061380518 (32Bit) Binary: 10110110011110001111010110100110 Tri-State: not applicable PulseLength: 618 microseconds Protocol: 2
Raw data: 6196,1072,592,524,1172,1080,600,1076,584,528,1156,1080,592,1080,604,528,1148,532,1148,1080,584,1108,592,1084,596,1076,608,524,1152,528,1152,520,1164,1084,592,1080,600,1076,588,1104,596,524,1156,1100,584,528,1144,1088,596,1080,584,548,1144,1088,600,512,1148,524,1144,1084,600,1100,588,520,1176,


Den einzigen Unterschied, den ich aktuell noch sehe ist die Pulselänge die beim funktionierenden Signal 639ms und bei FHEM 618ms beträgt.

Dann habe ich mir aus dem Log noch folgenden Eintrag als Grundlage für einen RAW Befehl verwendet:

Code Auswählen Erweitern

Sduino/msg READ: MU;P0=-1365;P1=477;P2=1145;P3=-734;P4=-6332;D=01023202310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232;CP=1;R=12;O;

Daraus habe ich dann folgenden Befehlt konstruiert:

Code Auswählen Erweitern

set Sduino raw SR;;R=12;;P0=-1365;;P1=477;;P2=1145;;P3=-734;;P4=-6332;;D=01023202310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232323231023102323102310102323102423102323102323101023232323101010232;;

Das Ergebnis ist aber leider noch ernüchternder - da sendet FHEM überhaupt nichts.

Jetzt wäre meine Frage - kann ich die Pulslänge irgendwie beeinflussen?
Schließlich scheint das der einzige Grund zu sein, warum der Schalter nicht schält.

[litronics]

So - hab den "Fehler" gefunden. Zumindest wenn man es nicht Dummheit nennen will.

Mit dem RAW Befehl sowie sendMSG schält der Schalter einwandfrei - zumindest wenn nicht zu viele Wände dazwischen sind. Die Reichweite einer 868MHz Antenne bei 433MHz ist dann doch etwas begrenzt 

Herzlichen Dank nochmal an alle die konstruktiv geholfen haben.

[andies]

Anscheinend sind die Probleme ja gelöst. Trotzdem zwei Anmerkungen:

• Vergleichbare raw-Befehle, die du oben zeigst, hatte ich auch mal empfangen. Bis mir klar wurde, dass bei Zeiten unter 50 der Receiver unzuverlässig ist. Und in der Tat war mein Empfänger so schrottig, dass ich ihn dann entsorgt habe, weil er mich ständig auf eine falsche Fährte lockte. Nimmst Du den MX-05 oder wie der heißt, für 1$ in der Bucht? Ich vermute ernsthaft, dass da ein Problem vorliegt.
• Ich habe auch so ein RSL-Ding ausgelesen und ziemlich genau die Zeiten gefunden, die Du dann zum Senden nimmst: https://forum.fhem.de/index.php/topic,39411.msg706934.html#msg706934

Leider habe ich es nicht geschafft, dass mal in einem Modul umzusetzen. Da ich aber nur einen RSL habe, steuere ich den mit raw-Befehlen des Signalduino, mir reicht das.