Hallo,
bin ein unbeschriebenes Blatt was Home Automation und FHEM betrifft und habe es bisher noch nicht geschafft, erste 433MHz Geräte über FHEM mit dem CUL433 zu steuern.
Ich habe als Testgeräte ein Conrad-Steckdosenset im Einsatz, der Typ lautet RSL88T/B.
Nun lässt sich im Protokoll (mit set CUL raw X25) sehen, dass bei Betätigung der Conrad-Fernbedienung Messages gesendet werden. Der Inhalt sieht wie folgt aus:
2013.09.01 08:47:59 2: CUL: unknown message p 3 1200 640 512 1296 4 2 0 70 EC3F
2013.09.01 08:47:59 2: CUL: unknown message p 3 1168 656 512 1280 4 2 0 6E EC3F
2013.09.01 08:47:59 2: CUL: unknown message p 3 1232 592 560 1248 4 2 0 70 EC3F
2013.09.01 08:47:59 2: CUL: unknown message p 3 1264 576 592 1200 4 2 0 74 EC3F
2013.09.01 08:47:59 2: CUL: unknown message p 3 1264 528 608 1184 4 2 0 74 EC3F
Relevant erscheinen mir insbesondere die letzten drei Bytes, also beispielsweise 74EC3F... ich schildere dazu mal meine Beobachtungen und liege damit möglicherweise völlig falsch, aber zumindest habe ich eine Theorie. :-)
1. Die message wird offenbar mehrmals gesendet - was ja grundsätzlich kein Hindernis sein sollte.
2. Der Inhalt der Message ist bei Wiederholung zwar unterschiedlich, unterscheidet sich jedoch nur gering (70, 6E, 74). D.h. ich gehe davon aus, dass es sich um eine gewisse Unschärfe durch das analoge Signal handelt. Wenn ich eine andere Taste auf der Fernbedienung betätige, ist der Inhalt doch deutlich unterscheidbar.
Nun möchte ich im Prinzip diese empfangenen Messages senden um damit anstelle der Fernbedienung über FHEM die Steckdose zu steuern. In einem ersten Versuch habe ich dies über set CUL raw versucht, bin damit jedoch gescheitert...
Daher die Frage: Ist diese Vorgehensweise grundsätzlich überhaupt möglich oder bin ich auf dem falschen Weg?
Auf der Conrad-Fernbedienung steht ein 10-stelliger aufgeklebter Code der aus Ziffern von 0 bis 4 besteht... ich erinnere mich gelesen zu haben, dass dies in irgendeiner Form mit übertragen wird, wüsste aber nicht wie.
Es sollte doch möglich sein diese Conrad-Steckdosen, die vermutlich relativ verbreitet sind, über FHEM mit dem 433MHz CUL zu steuern, oder?
Vielen Dank für eure Hilfe
Dieses Protokoll wird weder von FHEM noch vom culfw unterstuetzt, obwohl es vermutlich machbar ist. Was mich etwas beunruhigt sind die 16 Bits an Dateninhalt (== Adresse+Schaltbefehl+CRC), kommt mir etwas wenig vor.
Fuer den Inhalt der p-Zeilen siehe http://culfw.de/commandref.html#protocol2 (//culfw.de/commandref.html#protocol2) , um Daten experimentell zu senden siehe http://culfw.de/commandref.html#cmd_G (//culfw.de/commandref.html#cmd_G)
In diesem Stadium sollte man erst ohne fhem, nur mit einem Terminal bearbeiten.
Wenn man es culfw integrieren will, dann sollte man erst culfw soweit erweitern, dass die Befehle richtig empfangen (crc-check, etc), und gesendet werden, und danach in FHEM einen Modul schreiben.
Koenntest Du uns noch ein Link im Conrad Shop geben, ich habe unter RSL88T/B nix gefunden.
Ich würde hier die Vermutung aufstellen, dass es sich vielleicht um ein Intertechno (oder IT ähnliches) Protokoll handelt. Es könnte sein, dass ein Teil der Daten hier als sync-Folge erkannt wird und der Dateninhalt in wirklich größer ist.
Hallo,
vielen Dank für eure Antworten und sorry, dass ich mich erst jetzt wieder melde - aber ich habe nur am Wochenende Zeit mich intensiv damit zu beschäftigen. :-)
Eure Vermutungen bestätigen sich wie es aussieht - die empfangene Message ist unvollständig. Ich habe auf der Fernbedienung die Taste gedrückt, die alle Geräte ausschaltet. Dies führt laut Protokoll zur Zeichenfolge EC3F - also wie schon festgestellt eine 16bit Folge. Interessanterweise wird aber auch bei der ON-Taste die identische Bitfolge, d.h. auch EC3F, zurückgeliefert. Ich gehe daher davon aus, dass EC3F sowas wie die "Gerätegruppe" darstellt (falls diese überhaupt vollständig ist) und die fehlende Komponente der Schalt-Befehl ist. D.h. die einfachste Idee die ich dazu hatte ist, anstelle von zwei Bytes 4 Bytes zu senden und diese auf 0000 bzw. FFFF für aus/ein zu setzen - leider hat das aber nicht funktioniert. Soweit ich bisher aber recherchiert habe scheint Conrad ein ähnliches Protokoll wie Intertechno zu verwenden.
Habt ihr noch Ideen dazu, wie man zu einem vollständigen Signal kommen könnte?
Ach ja, ich habe inzwischen natürlich auch den link zur Conrad-Seite: http://www.conrad.at/ce/de/product/640454/Funk-Steckdosen-4teiliges-Sparset-RSL2-Reichweite-max-70-m-im-Freifeld/?ref=detview1&rt=detview1&rb=2 (//www.conrad.at/ce/de/product/640454/Funk-Steckdosen-4teiliges-Sparset-RSL2-Reichweite-max-70-m-im-Freifeld/?ref=detview1&rt=detview1&rb=2)
Danke nochmal für eure Hilfe
Ich hab' mal die IT-Erkennung in der CUL Firmware angepasst, damit sie etwas besser auf diese Signale passt. Wenn der Sync-Pulse ähnlich wie beim IT-Protokoll ist, würde man was erkennen können. Zumindest sollte man vielleicht etwas mittels X25 erkennen können (hab' ich ein wenig angepasst um die sync Signallänge ausgeben zu können).
Vielen Dank für die Anpassung und sorry wegen der späten Antwort - ich habe leider erst wieder dieses Wochenende Zeit mich damit zu beschäftigen, bin aber inzwischen mit meinen Recherchen ein Stück weiter gekommen.
Es stimmt, dass es ein Intertechno-ähnliches Protokoll ist... aber eben nur ähnlich. Theoretisch könnte man die Geräte mit einer IT-Fernbedienung sogar anlernen, aber mir wäre eine allgemeingültige Lösung für die Integration in FHEM mit CUL doch deutlich lieber.
In einem anderen Forum (http://www.mikrocontroller.net/topic/252895 (//www.mikrocontroller.net/topic/252895)) habe ich eine wesentliche Info zu den Conrad-Geräten gefunden, nämlich, dass es grundsätzlich eine 32bit Folge ist, die wie folgt aussieht:
2 bit offenbar konstant 10
2 bit Tasten 1-4
2 bit ein/aus
2 bit Wahlschalter 1-4 auf der Fernbedienung
24 bit Fernsteuerungs-ID
Das Ergebnis sollte dann in etwa so aussehen:
1.1 AN
10110110110100101011100111000000
1.1 AUS
10111110110100101011100111000000
1.2 AN
10001110110100101011100111000000
1.2 AUS
10000001110100101011100111000000
1.3 AN
10100110110100101011100111000000
1.3 AUS
10101110110100101011100111000000
1.4 AN
10010110110100101011100111000000
1.4 AUS
10011110110100101011100111000000
Ausserdem glaube ich nun aufgrund dieses Beitrags die Sync-Folge zu kennen, nämlich 1x HIGH und 10x LOW.
Darüber hinaus soll auch noch folgendes zutreffen:
eine 1: 2xHIGH 1xLOW
eine 0: 1xHIGH 2xLOW
PulseLength: 650
Die Frage ist nun - kann man dem CUL beibringen das zu lesen und zu senden? Mein Problem ist vor allem, dass ich ohne vorheriges Lesen die Fernbedienungs-ID nicht kenne und somit bei 24bit auch keine Chance habe es auszuprobieren. Zwar ist auf der Fernbedienung ein Aufkleber mit "1212000342", aber ich wüsste nicht, wie sich das in einen 24bit Code umrechnen lassen sollte - gehen wir davon aus, dass es im 10er-System angegeben ist, so reichen 24bit zur binären Codierung nicht aus. Ich habe bereits versucht es so umzurechnen, dass nur Ziffern von 0..4 vorkommen können, aber das scheint auch nicht die Lösung zu sein.
Vielen Dank für eure Hilfe
Ach ja, das hatte ich vorher ganz vergessen - mit der angepassten Firmware bekomme ich übrigens jetzt Output wie diesen:
2013.09.21 15:05:48 2: CUL: unknown message p 3 1168 656 512 1264 4 2 0 240 7216 60 EC3F
2013.09.21 15:05:48 2: CUL: unknown message p 3 1184 640 512 1296 4 2 0 0 0 60 EC3F
2013.09.21 15:05:48 2: CUL: unknown message p 3 1200 608 512 1264 4 2 0 0 0 5E EC3F
2013.09.21 15:05:48 2: CUL: unknown message p 3 1184 640 480 1280 4 2 0 160 8528 5E EC3F
2013.09.21 15:05:48 2: CUL: unknown message p 3 1168 624 512 1264 4 2 0 240 7216 5E EC3F
2013.09.21 15:05:55 2: CUL: unknown message p 3 1200 608 544 1248 5 3 0 0 0 56 A1EC3F
2013.09.21 15:05:55 2: CUL: unknown message p 3 1216 608 576 1216 5 3 0 0 0 54 A1EC3F
2013.09.21 15:05:55 2: CUL: unknown message p 3 1216 608 544 1248 5 3 0 160 8528 54 A1EC3F
2013.09.21 15:05:55 2: CUL: unknown message p 3 1216 576 592 1184 5 3 0 240 7216 54 A1EC3F
2013.09.21 15:05:55 2: CUL: unknown message p 3 1264 576 560 1216 5 3 0 0 0 55 A1EC3F
2013.09.21 15:06:04 2: CUL: unknown message p 3 1152 640 512 1264 4 2 0 0 0 58 EC3F
2013.09.21 15:06:04 2: CUL: unknown message p 3 1168 640 512 1264 4 2 0 160 8528 58 EC3F
2013.09.21 15:06:04 2: CUL: unknown message p 3 1168 656 480 1296 4 2 0 240 7216 58 EC3F
2013.09.21 15:06:04 2: CUL: unknown message p 3 1232 576 560 1200 4 2 0 0 0 56 EC3F
2013.09.21 15:06:04 2: CUL: unknown message p 3 1216 608 576 1216 4 2 0 0 0 56 EC3F
2013.09.21 15:06:13 2: CUL: unknown message p 3 544 1232 1184 624 6 3 0 160 8528 54 5E13C0
2013.09.21 15:06:13 2: CUL: unknown message p 3 576 1200 1216 608 6 3 0 240 7216 54 5E13C0
Hmm, eigentlich hatte ich mehr erwartet. Da sollten eigentlich einige "p 7 ...." messages auftauchen - der Rest scheint aber zu stimmen. Versuch mal etwas mit den Funk Parametern zu spielen oder auch den Abstand zwischen Empfänger und Sender zu variieren (zu nah ist nicht immer gut).
Hi,
also ich hab es jetzt mit jeder denkbaren Distanz getestet - das Ergebnis ist leider das selbe, es sind ausschließlich "p 3" messages. Was die Funkeinstellungen betrifft, so habe ich diese mit x00..x09 variiert und es hat auch keine Veränderungen mit sich gebracht.
Allerdings habe ich mir heute ein kleines Tool zur Signalanalyse entwickelt und ich glaube, dass ich nun die Fernbedienungs-ID kenne... genau genommen bin ich mir sogar sicher. :-)
Dazu habe ich zwei Screenshot hochgeladen, der erste zeigt das Signal visualisiert (von CUL über X3D ausgelesen). Es sind dabei 34 Flankenwechsel zu sehen, wobei wir davon ausgehen können, dass die ersten zwei davon lediglich die Synchronisierungsfolge ist. D.h. das Signal besteht wie bereits erwähnt aus 32 bit, die durch diese Flankenwechsel repräsentiert werden - 2x HIGH und 1x LOW bedeutet 1 und 1x HIGH und 2x LOW bedeutet 0.
(siehe Anhang / see attachement)
Der zweite Screenshot ist nur ein Auszug aus einem Excel-Sheet das die ersten Ergebnisse der Analyse zeigt - die Fernbedienungs-ID sind die letzten 24 bit und der Rest ist soweit auch klar. Ein Pulslänge von 650 scheint auch im Durchschnitt eine gute Wahl zu sein.
(siehe Anhang / see attachement)
Nun ist die Frage - wie kann ich über den CUL ein solches Signal senden? Ich gehe davon aus, dass ich berücksichtigen muss, dass wie oben beschrieben 2x HIGH und 1x LOW für 1 steht und 2x LOW und 1x HIGH für 0 steht. D.h. ich kann meines Erachtens nicht einfach 32bit, d.h. über RAW 4 Bytes senden, da ich damit diesem Umstand nicht Rechnung tragen würde. Ist es überhaupt möglich mit der aktuellen Firmware ein solches Signal zu senden?
Eine weitere Frage - wie sind die beiden Synchronisierungsflanken zu deuten?
Vielen Dank nochmal für eure Hilfe!
Hallo nochmal,
ich hab es jetzt mit G104026254E4E25B65E13C0 getestet... damit sollte die Message für 1.1 ON (siehe Screenshot oben) gesendet werden... wie üblich schaltet sich das Gerät jedoch nicht ein - gibt es irgendetwas offensichtliches in der Syntax, was ich falsch mache?
Zitatich hab es jetzt mit G104026254E4E25B65E13C0 getestet... damit sollte die Message für 1.1 ON (siehe Screenshot oben) gesendet werden... wie üblich schaltet sich das Gerät jedoch nicht ein - gibt es irgendetwas offensichtliches in der Syntax, was ich falsch mache?
Mit "G" wirst du das Signal nicht konstruiert bekommen, da der Sync Teil nicht aus x Nullen(=1L+2H) und einer Eins(=2H+1L) besteht.
Was ich aber immer noch nicht verstehe ist wie genau die Sync-Folge aussieht. Wenn deine Angaben stimmen sollte es ja 600High und 6000L sein, richtig?
Ich bau dir nochmal eine Firmware mit weit ausgedehnten Parametern...
Hi,
vielen Dank für die neue Firmware - für meine Zwecke würde ich übrigens mit der V3 schon auskommen. :-)
Ich komme leider damit noch immer nicht soweit, dass die Geräte auf das Signal reagieren - wobei ich sicher bin, dass es nur noch um das Sync-Signal gehen kann.
Laut dem bereits erwähnten Forum besteht das Sync-Signal bei einer Puls-Länge von 650 aus 1x HIGH und 10 LOW, d.h. es sollte eine steigende Flanke mit einer Länge von 650 geben und eine sinkende Flanke mit einer Länge von 6500... aber das passt nicht zu dem was ich aus dem CUL mit X3D raus analysiert habe...
Wie du in der Grafik oben sehen kannst scheint das Sync-Signal aus vier Flanken zu bestehen... jeweils eine kurze HIGH gefolgt von einer längeren LOW. Die Länge lässt sich nicht ganz exakt ermitteln, da bei praktisch jedem Versuch Abweichungen gegeben sind - aber im Schnitt sind es so ca. 770 HIGH, 2330 LOW, 670 HIGH und 2500 LOW... erst nach diesen vier Flanken kommen dann die 32 Datenbits, bei denen über eine durchschnittliche Pulslänge von 600 bis 650 2x HIGH, 1xLOW = 1 und 1x HIGH, 2x LOW = 0 repräsentiert wird. Dieser Teil sieht für mich vollständig schlüssig aus, zumal es sich auch 1:1 den Angaben entspricht, die ich gefunden habe. D.h. die große Unbekannte bleibt die Sync-Folge. Kann man davon ausgehen, dass CUL die Flanken auch für ein unbekanntes Protokoll wie dieses die Sync-Folge richtig ausgibt? Also ist es wirklich so low-level, dass das Protokoll in dem Fall nicht wichtig ist?
Ich fände es schon großartig, das Conrad-RSL Protokoll mit dem CUL verwenden zu können, zumal die Komponenten relativ kostengünstig sind und zumindest über die Fernbedienung absolut zuverlässig funktionieren. Inzwischen hab ich eben auch ein Tool gebastelt um die Fernbedienungs-ID über CUL ermitteln zu können, das würde ich dann inklusive Anleitung im WIKI natürlich auch gerne Zur Verfügung stellen, auch wenn es sicher nicht allzu sauber ist erfüllt es doch seinen Zweck.
Eine Frage ganz allgemeiner Natur - wäre es eigentlich nicht sehr hilfreich den Output den X3D liefert (also vor allem die rXfY Folgen) auch mit einer ähnlichen Codierung an den CUL übergeben zu können? Damit wäre dann im Prinzip jedes beliebige Signal inklusive beliebiger Sync-Folge konstruierbar. Vielleicht stelle ich mir das aber auch deutlich zu einfach vor. :-)
Zitat von: JorEl schrieb am So, 29 September 2013 12:04Hi,
vielen Dank für die neue Firmware - für meine Zwecke würde ich übrigens mit der V3 schon auskommen. :-)
Ich komme leider damit noch immer nicht soweit, dass die Geräte auf das Signal reagieren - wobei ich sicher bin, dass es nur noch um das Sync-Signal gehen kann.
Es ging mir erst mal um das Empfangen mit der CUL. Siehst du mit dieser Firmware einige "p 7.." Meldungen? Dann wären wir ein gutes Stück weiter.
ZitatLaut dem bereits erwähnten Forum besteht das Sync-Signal bei einer Puls-Länge von 650 aus 1x HIGH und 10 LOW, d.h. es sollte eine steigende Flanke mit einer Länge von 650 geben und eine sinkende Flanke mit einer Länge von 6500... aber das passt nicht zu dem was ich aus dem CUL mit X3D raus analysiert habe...
Wie du in der Grafik oben sehen kannst scheint das Sync-Signal aus vier Flanken zu bestehen... jeweils eine kurze HIGH gefolgt von einer längeren LOW. Die Länge lässt sich nicht ganz exakt ermitteln, da bei praktisch jedem Versuch Abweichungen gegeben sind - aber im Schnitt sind es so ca. 770 HIGH, 2330 LOW, 670 HIGH und 2500 LOW... erst nach diesen vier Flanken kommen dann die 32 Datenbits, bei denen über eine durchschnittliche Pulslänge von 600 bis 650 2x HIGH, 1xLOW = 1 und 1x HIGH, 2x LOW = 0 repräsentiert wird. Dieser Teil sieht für mich vollständig schlüssig aus, zumal es sich auch 1:1 den Angaben entspricht, die ich gefunden habe. D.h. die große Unbekannte bleibt die Sync-Folge. Kann man davon ausgehen, dass CUL die Flanken auch für ein unbekanntes Protokoll wie dieses die Sync-Folge richtig ausgibt? Also ist es wirklich so low-level, dass das Protokoll in dem Fall nicht wichtig ist?
Ich bin mir jetzt grad nicht ganz sicher, aber ich glaube du kannst mit dem Verfahren (X3D) nicht so lange LOW Phasen erkennen. So dass, das was wir dort sehen vielleicht nicht korrekt ist.
ZitatIch fände es schon großartig, das Conrad-RSL Protokoll mit dem CUL verwenden zu können, zumal die Komponenten relativ kostengünstig sind und zumindest über die Fernbedienung absolut zuverlässig funktionieren. Inzwischen hab ich eben auch ein Tool gebastelt um die Fernbedienungs-ID über CUL ermitteln zu können, das würde ich dann inklusive Anleitung im WIKI natürlich auch gerne Zur Verfügung stellen, auch wenn es sicher nicht allzu sauber ist erfüllt es doch seinen Zweck.
Eine Frage ganz allgemeiner Natur - wäre es eigentlich nicht sehr hilfreich den Output den X3D liefert (also vor allem die rXfY Folgen) auch mit einer ähnlichen Codierung an den CUL übergeben zu können? Damit wäre dann im Prinzip jedes beliebige Signal inklusive beliebiger Sync-Folge konstruierbar. Vielleicht stelle ich mir das aber auch deutlich zu einfach vor. :-)
Möglich wäre das bestimmt. Ich könnte mir aber eher vorstellen den "G" Befehl entsprechend um flexible Sync Folgen zu erweitern.
Hi,
du hast absolut recht, es gib jetzt auch p 7 messages:
2013.09.29 15:49:17 2: CUL: unknown message p 7 480 1296 1152 656 1 4 0 688 6512 4C B65E13C0
2013.09.29 15:49:17 2: CUL: unknown message p 3 1216 592 560 1248 4 2 0 768 7072 45 EC3F
2013.09.29 15:49:17 2: CUL: unknown message p 7 528 1248 1216 592 1 4 0 768 6656 40 B65E13C0
2013.09.29 15:49:17 2: CUL: unknown message p 7 544 1248 1216 576 1 4 0 784 6688 40 B65E13C0
2013.09.29 15:49:18 2: CUL: unknown message p 7 560 1232 1248 576 1 4 0 720 6784 42 B65E13C0
2013.09.29 15:49:24 2: CUL: unknown message p 7 560 1216 1216 608 1 4 0 704 6432 48 B65E13C0
2013.09.29 15:49:24 2: CUL: unknown message p 7 576 1200 1232 576 1 4 0 768 7024 4A B65E13C0
2013.09.29 15:49:24 2: CUL: unknown message p 7 608 1168 1280 528 1 4 0 784 6848 4A B65E13C0
2013.09.29 15:49:24 2: CUL: unknown message p 7 592 1184 1248 560 1 4 0 784 6688 4C B65E13C0
2013.09.29 15:49:24 2: CUL: unknown message p 7 560 1232 1232 576 1 4 0 784 6688 4A B65E13C0
2013.09.29 15:49:27 2: CUL: unknown message p 7 592 1184 1280 528 1 4 0 640 6496 3C BE5E13C0
2013.09.29 15:49:27 2: CUL: unknown message p 7 608 1168 1248 576 1 4 0 784 6960 3C BE5E13C0
2013.09.29 15:49:27 2: CUL: unknown message p 7 608 1168 1216 592 1 4 0 880 6752 3C BE5E13C0
2013.09.29 15:49:27 2: CUL: unknown message p 7 608 1168 1280 528 1 4 0 800 6688 3C BE5E13C0
2013.09.29 15:49:27 2: CUL: unknown message p 7 608 1168 1280 528 1 4 0 800 6768 3C BE5E13C0
Der Inhalt ist auch völlig korrekt und entspricht dem Ergebnis meiner Analyse via X3D. D.h. 5E13C0 ist die Fernbedienungs-ID und das erste Byte ist der Steuerbefehl.
Großartig, dass es jetzt richtig gelesen wird. :-) Aber mir ist leider noch nicht ganz klar, wie es uns nun hilft das Signal zu senden...
ZitatMöglich wäre das bestimmt. Ich könnte mir aber eher vorstellen den "G" Befehl entsprechend um flexible Sync Folgen zu erweitern.
Das wäre natürlich noch besser, denn der Rest von "G" ist ja im Prinzip völlig flexibel, im Prinzip geht es nur um die Sync-Folge.
Vielen Dank für Deine Unterstützung!
sehr schön.
Damit sieht die CUL also den Sync Pulse mit etwa 750 zu 6800. Damit sollte ein Senden/Empfangen zu implementieren sein. Ich überlege noch, ob es Sinn macht "G" bzw. "i" zu "missbrauchen", oder es besser wäre ein eigenen Befehl zu erfinden...
ZitatIch überlege noch, ob es Sinn macht "G" bzw. "i" zu "missbrauchen", oder es besser wäre ein eigenen Befehl zu erfinden...
Ich denke "i" ist ein wenig zu weit weg bzw. einfach zu unterschiedlich, das Protokoll hat zwar schon Ähnlichkeiten zu Intertechno, aber es ist dennoch in mehreren Punkten unterschiedlich.
"G" mit flexiblem Sync wäre sicher eine gute Möglichkeit - im Grunde genommen wäre es unabhängig von diesem Thema großartig, diese Flexibilität beim Senden von RAW-Daten zu senden. :-)
Aber ein eigener Befehl wäre natürlich eine großartige Sache - eine nicht geringe Menge an Hardwarekomponenten die das Conrad RSL nutzt gibt es schließlich, noch dazu relativ kostengünstig verglichen mit anderen Geräten. :-)
So, habe mal versucht "G" zu erweitern. Ich kann aber leider nicht selber testen.
Die Syntax sieht dann so aus:
GXhhhhllllssNnprHHLLhhllDDDD...
wobei hhhh = Sync Pulse Hightime (in 16us)
und llll = Sync Pulse Lowtime (in 16us)
Der Rest bleibt wie gehabt. Folgt kein "X" nach dem "G" bleibt alles beim alten.
Die sync Anzahl solltest du auf 0 setzen, sonst werden beide Sync Methoden verwendet.
Viel Glück
Hallo,
danke für die angepasste Firmware. Ich hab es jetzt mal getestet und wie es aussieht stürzt CUL nach dem ersten Versuch ab... ich kann zumindest keinen zweiten Befehl mehr ausführen und in meinem Testprogramm kommt es zu einer write-exception auf den seriellen Port.
Mein Testbefehl war GX002E01A900400528515128BE5E13C0 - wenn ich es richtig verstanden habe, dann sind die hhhh und llll Angaben im konkreten Fall 750 / 16 = 46 --> 0x002E bzw. 6800 / 16 = 425 --> 0x01A9, oder sind diese Parameter nicht als Hex-Werte zu übergeben?
Es sieht dann so aus:
GX[hhhh=002E][llll=01A9][sync=00][N=4][n=0][p=0][r=5][HH=28 --> Dez. 40 --> *16 = 640][LL=51 --> Dez. 81 --> *16 = 1296][hh=51][ll=28][DDDD=BE5E13C0]
Wende ich die Syntax wirklich vollständig korrekt an? Nur um eine mögliche Fehlerquelle hier auszuschließen...
Habe natürlich auch versucht llll und hhhh als Dezimalzahlen zu übergeben, das führt jedoch ebenfalls dazu, dass beim nächsten Aufruf wieder eine Exception auftritt.
Genau richtig hhhh, llll sind in hex.
Ich glaub ich hab den Bug gefunden...
Hi,
perfekt, es funktioniert jetzt absolut zuverlässi und die Distanz ist offenbar deutlich höher als mit der Fernbedienung. :-)
Vielen, vielen Dank für die Hilfe!
Hab nun zwar schon das nächste kleine "Problem" damit es in die Oberfläche von fhem einzubauen, aber ich denke dazu mache ich besser ein eigenes Thema auf.
Das freut mich.
Hi,
ich muss das Thema nochmal ansprechen - aber nur wegen einer - hoffentlich lösbaren - Kleinigkeit. :-)
Wäre es möglich, den Sourcecode der culfw-Anpassungen zu bekommen? Ich bastel nun auch zunehmend damit rum und die Original-Firmware enthält ja soweit ich gesehen habe noch nicht diese Erweiterung...
Vielen Dank im Voraus!
Hi,
sorry, wenn ich das Thema nochmal nach vorne reihe... ich hab nun auch am SVN nachgesehen und die Anpassungen, mit denen RSL sehr gut funktioniert, sind wohl leider auch dort nicht enthalten - oder ich lese den Code nicht richtig. :-)
Könnte ich die Veränderungen bitte bekommen bzw. gegebenenfalls auch nur eine kurze Info, was angepasst werden muss, um zum selben Ergebnis zu kommen?
Vielen Dank
hier nun endlich die Code Anpassungen...