Belfox 433MHz Handsender dekodiert - Senden mit CUL433

Begonnen von fichtennadel, 01 Mai 2015, 11:46:19

Vorheriges Thema - Nächstes Thema

fichtennadel

Hallo,

ich habe die letzten Nächte damit verbracht die Funksignale eines Handsenders vom Typ Belfox 433MHz "Beschriftbarer Handsender (2 Tasten)" zu dekodieren (Foto siehe Anhang).

Der Sender verwendet eine OOK/ASK Modulation auf 433.92MHz und sendet einen im Grunde recht einfachen Code:
1bit Syncbit = 0
10bit "Handsendercode"
2bit "Tastencode"

Das ganze vier mal wiederholt.

Handsendercode: entspricht den Stellungen der DIP Schalter auf der Platine.
Tastencode:
11 obere Taste
10 untere Taste

Es gibt auch Varianten mit 4 Tastern, da wird die Belegung vermutlich analog zu erweitern sein, habe ich aber mangels Exemplar nicht getestet.

Die Kodierung im Signal:
0:  900us high, 1980us low
1: 1810us high,  990us low

35ms Pause zwischen den vier Wiederholungen

Jetzt wollte ich das Signal über meinen CUL433 (V3.4, culfw V 1.63) senden, scheitere aber an den Möglichkeiten (bzw. meinen Kenntnissen) des G Befehls in der culfw, das Signal ausreichend genau zu wiederholen.

Folgende Eigenheiten des Signals habe ich nicht geschafft mit dem G Befehl zu erzeugen:

  • Der Sender scheint nach jedem Wechsel von 1->0 ein zusätzliches low von +900us einzulegen aber umgekehrt bei 0->1 das low auf 900us zu reduzieren. (rot im Screenshot)
    Kodierung AUS/AN anstatt AN/AUS
  • Das letzte 0bit fehlt beim Senden mit CUL G (blau im Screenshot)
  • Sync ist kein 01 wie im G Befehl des CUL, sondern nur eine 0 (mit kürzerem low, siehe Punkt 1)
  • 35ms Pause kann G anscheinend nicht, maximal 16ms

An dieser Stelle jetzt meine Frage und bitte um Hilfestellung: bekommt man das doch über den G Befehl hin oder muss man das direkt in der culfw implementieren?

In letzterem Fall wäre ich dankbar für Hinweise auf ein Beispiel in den culfw Sourcen, an Hand dessen ich das versuchen kann zu implementieren. Über Unterstützung dabei würde ich mich sehr freuen.

Edit 2.5.2015: Eigenheiten korrigiert und das Senden funktioniert jetzt mit angepasster culfw, siehe Beitrag 4.

Beste Grüße,
Georg
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

rudolfkoenig

Ich gehe davon aus, dass du culfw erweitern musst.

culfw sendet nach dem Muster AN/AUS, in deinem Fall wird aber AUS/AN benoetigt. Fuer eine Privatversion reicht es in culfw/clib/rf_send.c in der Funktion send_bit das letzte my_delay_us ganz nach vorne zu verschieben. Vorausgesetzt, ich habe das Problem richtig verstanden.

Fuer eine endgueltige Version koennte man send_bit,rawsend und sendraw mit einem zusaetzlichen Parameter erweitern. Oder du baust eine direkte Send-Funktion fuer BelFox ein, ganz ohne G.

fichtennadel

Danke für die Info und den Hinweis, dass das 0/1 und nicht 1/0 kodiert ist, das erklärt natürlich Punkte 1+3.

Der Vollständigkeit halber sei erwähnt, dass ich bereits erfolgreich schalten kann, allerdings mit anderer Hard- und Software: FS1000A Sender und pilight-send -p raw am RasPi.
Der Code und die Timings passen also.

Ich versuche das in die culfw einzubringen, ich hätte das nämlich gerne mit "richtiger" Hardware im Echtbetrieb  ;)
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

fichtennadel

#3
So, auch der CUL433 öffnet jetzt Tür&Tor mit BelFox.

Ich habe die aktuelle Firmware (V1.63, r518 aus SVN, Stand heute 2.5.2015) um die Funktion send_belfox erweitert. Vorlage war sendraw in rf_send.c, deren Anteile außerhalb der "Sendeschleife" ich 1:1 übernommen habe.

Sourcen belfox.c und belfox.h für clib/ im Anhang, ich habe in meiner Version in Devices/CUL/ auch board.h, cul.c und das makefile angepasst, damit man mit Lxxxxxxxxxxyy senden kann.
CUL_V3.hex hänge ich auch an, falls jemand nicht kompilieren mag.

Verwendung:
Lxxxxxxxxxxyy
xxxxxxxxxx ... Handsendercode: entspricht den Stellungen der DIP Schalter auf der Platine, zB 1110001010
yy         ... Tastencode: 11 obere Taste, 10 untere Taste

Beispiel: L111000101010


Wäre toll, wenn jemand mit etwas mehr culfw Erfahrung als ich einen Blick auf den Code in belfox.c werfen könnte, ob da keine groben Schnitzer enthalten sind, die bestehende Funktionalität stören. Bei meinen Tests wäre mir nichts aufgefallen, meine IT Dose schaltet immer noch.

Würde mich freuen, wenn mein Beitrag auf Interesse stößt und in die offizielle culfw integriert wird.

Edit: Noch ein Hinweis: entwickelt und getestet mit einem CUL 433. Ein CUL 868 müsste vorher auf 433 umschalten, was mein Code nicht macht.
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

fichtennadel

und hier noch ein Beispiel für die Einbindung in fhem:

define Garagentor dummy
attr Garagentor devStateIcon off:fts_garage_door_40 on:fts_garage_door_40@red
attr Garagentor room Tor
attr Garagentor setList on off
define act.Garagentor notify Garagentor set CUL_433 raw L111001100110
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

chris1284

ich habe den sender auch, auf welcher culfw basiert deine änderung? der offiziellen oder der fortgeschrittenen alternativen culfw?
es wäre toll wenn der funktionierende code hier http://forum.fhem.de/index.php/topic,35064.0.html mit einfließen würde

fichtennadel

Zitat von: chris1284 am 03 Mai 2015, 09:11:04
ich habe den sender auch, auf welcher culfw basiert deine änderung? der offiziellen oder der fortgeschrittenen alternativen culfw?
Siehe oben: aktuelle, offizielle Firmware (V1.63, r518 aus SVN, Stand gestern 2.5.2015)

Zitat von: chris1284 am 03 Mai 2015, 09:11:04
es wäre toll wenn der funktionierende code hier http://forum.fhem.de/index.php/topic,35064.0.html mit einfließen würde
Dem steht nichts im Wege, meine Sourcen sind ja oben angehängt. Wenn bjoernh das in die a-culfw integrieren will, nur zu. Der Aufwand jetzt nur dafür im github zu forken und zu mergen steht sich mMn nicht dafür: belfox.c +.h kann man 1:1 übernehmen und die Änderungen im makefile, cul.c und board.h sind ja nur Dreizeiler.

Du kannst ja bjoernh im a-culfw Thread auf diesen hier hinweisen, dann kann er entscheiden, ob er es einfließen lassen möchte.
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

rudolfkoenig

ZitatWürde mich freuen, wenn mein Beitrag auf Interesse stößt und in die offizielle culfw integriert wird.

Habs ohne Aenderungen eingecheckt.
Die aktuelle Version ist damit 1.65, die Aenderung betrifft aber nur CUL_V3 Besitzer.

chris1284

#8
in der a-culf ist die änderung ja nun auch drin.
bekomme aber
Zitat2015.05.28 21:07:01 3: set miniCUL raw L000000000010
2015.05.28 21:07:01 2: miniCUL: unknown message ? (L000000000010 is unknown) Use one of B C F i G M R T V W X e m l t x
2015.05.28 21:07:02 3: set miniCUL raw L000000000010
2015.05.28 21:07:02 2: miniCUL: unknown message ? (L000000000010 is unknown) Use one of B C F i G M R T V W X e m l t x
2015.05.28 21:07:12 3: set miniCUL raw L000000000010
2015.05.28 21:07:12 2: miniCUL: unknown message ? (L000000000010 is unknown) Use one of B C F i G M R T V W X e m l t x
2015.05.28 21:07:52 3: set miniCUL raw L000000000010
2015.05.28 21:07:52 2: miniCUL: unknown message ? (L000000000010 is unknown) Use one of B C F i G M R T V W X e m l t x
2015.05.28 21:07:57 3: Can't connect to socket!
2015.05.28 21:08:11 3: set miniCUL raw L000000000011
2015.05.28 21:08:11 2: miniCUL: unknown message ? (L000000000011 is unknown) Use one of B C F i G M R T V W X e m l t x

im log.

ah sehe gerade nur culV3.... was ist der grund?

fichtennadel

Zitat von: chris1284 am 28 Mai 2015, 21:10:24
in der a-culf ist die änderung ja nun auch drin.
bekomme aber
[...]
2015.05.28 21:07:01 2: miniCUL: unknown message ? (L000000000010 is unknown) Use one of B C F i G M R T V W X e m l t x
[...]

Musst Du bjoernh fragen, ob er das für den miniCUL auch kompiliert, sieht für mich nicht so aus. Ich hab's für den CUL 433 eingebaut.
RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

chris1284

ja habs gerade gesehen, er hat auch nur den v3 rein genommen, kompilier ich selbst

chris1284

mein fehler! ich ging fest davon aus das unser handsender auch 433 ist, ist aber 868...

MrStonedfire

Mahlzeit,

besitze nun auch eine Belfox bzw. Dickert Torsteuerung. (Denke die sind Baugleich)
Die neue FB hat jedoch aufgrund der größe gibt es bei dieser jedoch keine DIP Schalter mehr sondern einen Festen Code.

Jetzt zu meinen Problem.

Leider bekomme ich den CUL nicht angelernt.
Gesendet wird aber.
2023.04.08 19:57:13 3: set nanoCUL raw L011001100110
2023.04.08 19:57:13 5: DevIo_SimpleWrite nanoCUL: L011001100110

Das Funksiegnal von der originalen FB sieht so aus.

2023.04.08 20:00:41 4: CUL_Parse: nanoCUL omD4C94BE74023
2023.04.08 20:00:41 5: nanoCUL: dispatch omD4C94BE74023
2023.04.08 20:00:41 5: CUL_REDIRECT (mD4C94BE74023) length: 13 RSSI: -56.5
2023.04.08 20:00:41 5: CUL_REDIRECT (mD4C94BE74023) match Manchester COODE length: 13
2023.04.08 20:00:41 5: CUL_REDIRECT decode Oregon 2 (D4C94BE74023)
2023.04.08 20:00:41 5: bitdata: 110101001100100101001011111001110100000000100011
2023.04.08 20:00:41 5: OSV2 protocol detected (D4C94BE74023)
2023.04.08 20:00:41 5: CUL_REDIRECT: ERROR: To short: OSV2 protocol converted to hex: (108A17) with length (24) bits

2023.04.08 20:00:41 5: CUL_REDIRECT decode Oregon 3 (D4C94BE74023)
2023.04.08 20:00:41 5: bitdata: 110101001100100101001011111001110100000000100011
2023.04.08 20:00:41 5: CUL_REDIRECT decode Hideki (D4C94BE74023)
2023.04.08 20:00:41 5: nanoCUL: search in 110101001100100101001011111001110100000000100011

2023.04.08 20:00:41 5: protocol does not match, ignore received package (D4C94BE74023) Reason: Not a hideki protocol
2023.04.08 20:00:42 5: CUL_Read: nanoCUL /omD4C94BE74023

2023.04.08 20:00:42 4: CUL_Parse: nanoCUL omD4C94BE74023
2023.04.08 20:00:42 5: nanoCUL: dispatch omD4C94BE74023
2023.04.08 20:00:42 5: CUL_REDIRECT (mD4C94BE74023) length: 13 RSSI: -56.5
2023.04.08 20:00:42 5: CUL_REDIRECT (mD4C94BE74023) match Manchester COODE length: 13
2023.04.08 20:00:42 5: CUL_REDIRECT decode Oregon 2 (D4C94BE74023)
2023.04.08 20:00:42 5: bitdata: 110101001100100101001011111001110100000000100011
2023.04.08 20:00:42 5: OSV2 protocol detected (D4C94BE74023)
2023.04.08 20:00:42 5: CUL_REDIRECT: ERROR: To short: OSV2 protocol converted to hex: (108A17) with length (24) bits

2023.04.08 20:00:42 5: CUL_REDIRECT decode Oregon 3 (D4C94BE74023)
2023.04.08 20:00:42 5: bitdata: 110101001100100101001011111001110100000000100011
2023.04.08 20:00:42 5: CUL_REDIRECT decode Hideki (D4C94BE74023)
2023.04.08 20:00:42 5: nanoCUL: search in 110101001100100101001011111001110100000000100011

2023.04.08 20:00:42 5: protocol does not match, ignore received package (D4C94BE74023) Reason: Not a hideki protocol


1    2    3    4    5    6    7    8    9    10    11    12    13    14    15    16    17    18    19    20    21    22    23    24   
oben
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    01    00
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    11    01
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    01
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    10
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    01
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    10
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    10
11    01    01    00    11    00    10    01    01    00    10    11    11    10    01    11    01    00    00    00    00    10    10    10
Unten
11    01    01    00    11    00    10    01    01    00    10    11    11    10    10    11    01    00    00    00    00    10    10    00
11    01    01    00    11    00    10    01    01    00    10    11    11    10    10    11    01    00    00    00    00    10    01    00
11    01    01    00    11    00    10    01    01    00    10    11    11    10    10    11    01    00    00    00    00    10    01    00
11    01    01    00    11    00    10    01    01    00    10    11    11    10    10    11    01    00    00    00    00    10    00    10

Hat jemand eine idee wo ich noch ansetzen könnte ?

MfG
Dennis

fichtennadel

#13
Zitatset nanoCUL raw L011001100110

Wie hast Du diesen Wert "011001100110" bestimmt, ohne DIP Schalter?

Gedacht ist das so:
Zitat von: fichtennadel am 02 Mai 2015, 23:11:54Lxxxxxxxxxxyy
xxxxxxxxxx ... Handsendercode: entspricht den Stellungen der DIP Schalter auf der Platine, zB 1110001010
yy         ... Tastencode: 11 obere Taste, 10 untere Taste

Beispiel: L111000101010


Zu den Funksignalen, etwas anders formatiert:
"Oben"
1101010011001001010010111110 01 11010000000010 1010
"Unten"
1101010011001001010010111110 10 11010000000010 1000

Meine Vermutung(!):
Der erste Block "1101010011001001010010111110 " ist wohl statisch, vielleicht der Code des Senders.
Der zweite Block "01" bzw. "10" könnte der Tastencode sein.
Dritter Block "11010000000010" ist wieder statisch.
Vierter Block wechselt, vielleicht ein Zähler, Rolling Code, Prüfsumme oder etwas in der Art.


Aber abgesehen davon, dass die Bedeutung der im Signal kodierten Bits unklar ist: wenn die neue FB mehr als 12 Stellen verwendet, wird das von der aktuellen Belfox-Implementierung in der (a-)culfw nicht unterstützt, das Maximum sind hier 12 Stellen.

RasPi 2 B | JeeLink Classic [4x 30.3144it, 2x 30.3147it] | CUL 433 a-culfw V 1.04.01 [ IT-1500, ITM-100, Somfy Telis 1 RTS, BelFox ] | TCM ESP3 [ FSB61, FSB61NP, FT55, FMH4S, AP221 ] | Fronius | Modbus/TCP (Stiebel Eltron WP)

MrStonedfire

Zitat von: fichtennadel am 09 April 2023, 12:15:01
Zitatset nanoCUL raw L011001100110

Wie hast Du diesen Wert "011001100110" bestimmt, ohne DIP Schalter?

Ersteinmal danke für die Antwort.
Den Wert "011001100110" hatte ich nicht bestimmt bzw ausgelesehen von der FFB sondern selber gestaltet und versucht anzulehrnen.
Leider ohne Erfolg.

Ich wollte einmal was zu meiner Hardware sagen.

Mein empfänger ist der:
https://www.torix.de/dickert-funkmodul-433-920-mhz-am?c=1703

Meine Funk Fernbedinung:
https://www.torix.de/dickert-handsender-s5q-433-mhz-2-kanal-linearcode

und mein CUL ist ein NanoCUL mit CC1101 V 1.26.08 a-culfw.

Roling Code dürfte es nicht sein da die FFB als linearcode variante verkauft wird.

Ich denke das Dickert und Belfox die selbe Hardware verwendet.

Ich werde jetzt mal versuchen die MAHS 433 anzulernen und dann den Code via CUL zu senden.
Sobald er ankommt.
https://www.torix.de/dickert-handsender-mahs-433-mhz-1-kanal-dip-schalter