FSK mit dem SIGNALDuino

Begonnen von Ralf9, 22 Dezember 2019, 17:30:36

Vorheriges Thema - Nächstes Thema

plin

#30
Hi RaspII,

hier noch mal das komplette aktuelle Bild

Zitat von: RaspII am 25 Dezember 2019, 13:01:37
Hi nochmal,
ich habe Google bemüht und bin dabei auf folgenden Thead gestoßen:
https://github.com/RFD-FHEM/RFFHEM/issues/210
Wenn ich das richtig verstehe warst Du schon mal weiter und konntest Botschaften bei 868,000 Mhz empfangen, korrekt?

ja, ich kann mit folgenden Parametern
ccconf: freq:868.000MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

im ASK/OOK Mode senden. Eine der Oberwellen trifft genau die obere oder untere Frequenz des FSK-FM-Signals. Da der Empfänger es nicht so genau zu nehmen scheint, kann ich also OOK senden und er (halbes) FSK empfangen.  So bediene ich aktuell meine Rolläden und muss von Hand (per Fernbedienung) nachsteuern. Wie damals schon geschrieben, reagieren die Rolladen 1, 4 und 5 relativ sicher auf das Signal, 3 und 6 öfters mal, 2 habe ich noch nicht überzeugen können. Meine Hoffnung ist durch den Wechsel von OOK auf FSK saubere Codes mitschneiden und senden zu können, damit sich die Rolläden sauber/stabil ansteuern lassen.

Zitat von: RaspII am 25 Dezember 2019, 13:01:37
Vorschlag zur weiteren Vorgehensweise:
Sobald wir die Frequenz zu 100% kennen (als Delta zum nanoCUL) baue ich dir eine Version mit der korrekten Frequenz und wir machen uns an die Baudrate.
Je nach dem ob die MU Botschaften in Deinem ursprünglichen Thread korrekt sind, ist die Baudrate irgendwo bei 2500 Baud (die nächste Normbaudrate wäre dann 2400Baud)

Die Frequenzen habe aus Sicht des SDUINO meines Erachtens nach bereits ermittelt. Im Screenshot waren die aber nicht dargestellt. Ich habe die beiden URH-Screenshot noch mal beigefügt. Bei identischer Auflösung sind die beiden Signale meiner Meinung nach brauchbar identisch. Die im SDUINO eingestellte Trägerfrequenz ist 868.307 MHz, die per Register 15 eingestellte Deviation 25 khZ. Durch den direkten Vergleich der Signale der RIO FB und des SDUINO-Signals schneke ich mir die Korrektur der in URH evtl. falsch dargestellten Frequenzen. Bei der Frequenz kann ich bei einer Bandbreite von 58 kHz Daten empfangen. Also müssen die 868.307 MHz relativ gut passen.

Ich würde jetzt schauen, ob ich relativ stabile, brauchbare Code-Sequenzen empfangen/mitschneiden kann. Die Sync-Nibbles am Anfang des Signals geben schon Aufschluss darüber, ob die Qualität passt:

Der hier
P0=-32001;P1=15864;P2=-407;P3=412;P4=4008;P5=802;P6=-799;D=0123232323232323232323232425632563636363256363632563252563632525636325252525636325636325636363636363636363256363632563252563256363256363636363636363256325;
wird runtergebrochen in
01232323232323232323232324
Im Sync-Vorspann selektiere ich die mit sauberem Pattern 2323232323232323232323.

Danach kommen
25632563636363256363632563252563
63252563632525252563632563632563
63636363636363632563636325632525
63256363256363636363636363256325


Daraus ergibt sich dann in Hex
5EE9 986D FF74 B7FA

Die Sequenz
5EE9 986D
ist ein Random Code der sich von Tastendruck zu Tastendruck unterscheidet.

FF74 B7FA
Ist der eigentliche Steuercode.

Ciao, plin


FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

RaspII

Hallo,
ich habe versucht Deine Dekodierung nachzuvollziehen und bin gescheitert.
Hast Du eine Möglichkeit mit einem Oszi direkt am Sender zu messen?
3 Pins sind interessant: FSKDTA, ASKDTA und PDWN.
Einer dieser PINs müsste statisch sein, die andere müssten toggeln.
Je nachdem wie die Pins agieren wird ein bestimmtes Protokoll eingestellt, siehe Datenblatt Kapitel 3.4.6

RaspII

RaspII

#32
@plin:
was mir noch aufgefallen ist:
Meine Firmware empfängt noch mit GFSK, ich bau Dir noch ne 2-FSK = FSK Variante

Nachtrag:
Hab Dir zwei neue Varianten gebaut und oben angehängt, siehe:
https://forum.fhem.de/index.php/topic,106594.msg1005156.html#msg1005156
RaspII

plin

Kurzer Zwischenstand: Ich habe heute Morgen einige Frequenzen durchgespielt und geschaut, ob der SDUINO Codesequenzen ins Log schreibt:

ccconf: freq:868.287MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.290MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.291MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => teils/teils
ccconf: freq:868.292MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.297MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.302MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.307MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.312MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => ok
ccconf: freq:868.314MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => teils/teils
ccconf: freq:868.315MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no
ccconf: freq:868.317MHz bWidth:58KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud, Modulation:GFSK) => no

Wenn ich mal davon ausgehe, dass die Trägerfrequenz in der Mitte zwischen der oberen und unteren Frequenz bei der der Empafng nachlässt liegt, komme ich auf 868.302 MHz.

Die bei 868.302 MHz empfangenen Codesequenzen sind aber noch nicht so stabil wie ich mir das erhofft hatte:
D=012343434343434343434343435643764646437643737376464373764...
D=010101023101010231023231023101023101010101010101023102324...
D=012123030123030301212123030123012121212303030123030121212...
D=012121212121212121212121314525214145252525214141452141452...


@RaspII: jetzt wechsle ich auf Deine Firmware
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

Zitat von: RaspII am 24 Dezember 2019, 16:17:22
Hi,
habe Dir noch eine zweite Version gemacht mit der gewünschten deviation von ca. 25kHz

Die Datei oben habe ich gelöscht, im Anhang die selbe Datei aber mit Parameter im Namen

Nachtrag:

  • mit dieser Firmware kann man jeweils nur empfangen !
  • Datenrate wenn nicht im Dateinamen genannt = 4785,5
  • Modulation wenn nicht im Dateinamen genannt = GFSK

Ich habe die nanoCUL_f868.275dev25.39_2FSK_drate2498.hex und nanoCUL_f868.275dev25.39_2FSK.hex auf den SDUINO geflasht und jeweils krS3 abgesetzt, sehe im Log auch
SW: krS3
CUL/RAW: /krS-ReceiveStart
CUL_Parse: nanoCUL krS-ReceiveStart
nanoCUL: dispatch krS-ReceiveStart
nanoCUL: Unknown code krS-ReceiveStart, help me!

Empfangsseitig ist aber tote Hose, im Log rührt sich nichts.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

HomeAuto_User

Hallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...

Ist es nicht einfacher, einen Sender zu nehmen wo man weiß, er sendet mit dieser Modulation und macht sich erstmal an die Decodierung?

Irgendwie fehlt mir hier der feste Bezugspunkt manchmal ;)


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

RaspII

@plin
kannst du mit einem Terminal an den nanoCUL gehen?
Ich bin mir nicht sicher ob FHEM die Antworten weiterreicht
RaspII

plin

Zitat von: HomeAuto_User am 26 Dezember 2019, 11:08:50
Hallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...
Ist es nicht einfacher, einen Sender zu nehmen wo man weiß, er sendet mit dieser Modulation und macht sich erstmal an die Decodierung?
Irgendwie fehlt mir hier der feste Bezugspunkt manchmal ;)
Im Prinzip ja, nur liegen 2FSK und GFSK meiner Meinung nach nicht weit auseinander. Ich habe nur zwei Sender und kann vermutlich keinen mehr nachkaufen, deshalb bin ich mit Aktivitäten an sehr kleinen Pins bei denen man leicht einen Kurzschluss verurschachen sehr SEHR vorsichtig :-).

Mein Oszi ist ca. 40 Jahre alt. Vor einem Jahr bin ich schon mal an die Pins des Empfängers dran gegangen. Die Synchronisation/Auflösung war aber schwierig ...

Ich habe zum Vergleich mal drei Spektren mitgeschnitten (siehe Anlage). Die Original-FB sendet ein Signal ohne Oberwellen, während der CC101 bei GFSK ein seichtes Tal bei der Trägerfrequenz hat, mit 2FSK sind die Spitzen ausgeprägter. Die Oberwellen sind auch schärfer ausgeprägt als bei GFSK.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

Zitat von: RaspII am 26 Dezember 2019, 11:39:31
@plin
kannst du mit einem Terminal an den nanoCUL gehen?
Ich bin mir nicht sicher ob FHEM die Antworten weiterreicht
Ja, gerne, aber eine Frage geht mir schon seit gestern durch den Kopf: Ist Dein Sketch wirklich auf 868.275 MHz eingestellt? Wenn ich mit dem SDUINO FSK funke muss ich den auf 868.302 oder 868.307 MHz einstellen. Bei 868.275 MHz ist der Empfang auch mit dem SDUINO = 0.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Ralf9

#39
Verschoben von: "Antwort #3 am: 24 Dezember 2019, 10:20:56"
ZitatWenn mir es gelingt, daß ich mit dem sduino ein xFSK signal empfange, dann kann ich das Empfangen und Senden mit dem FIFO des cc1101 einbauen, dann wird einiges einfacher.
Es wird für das Signalduino Modul demnächst ein neuer set Befehl geben, damit kann dann eine folge von ccRegistern gesendet werden.
z.B. set sduino cc1101_reg 1183 1214 1363 14B9 1500 1BF8 1DCF

Mit dem Senden mit dem nanocul und der culw firmware und dem kopp Protokoll komme ich nicht weiter.
Mein Problem ist, daß ich nicht weiss ob das Problem beim Sender (nanocul) oder beim Empfänger (minicul) ist.
Wenn ich eine ITv1 Nachricht vom nanocul (mode slowrf) zum minicul sende, dann funktioniert es. Ich habe eine freq von 868.3 und eine Bandbreite von 162 verwendet.

Ich überlege mir gerade ob ich vielleicht mit der a-culw weiterkomme, da gibt es auch eine firmware für den minicul.
Ich würde gerne auch mal versuchen mit dem minicul ein xFSK zu senden.
Evtl komme ich mit dem mode 1 und 2 (IT+) weiter, nur wie kann ich da was senden?

Falls jemand eine xFSK Fernbedienung hat die er nicht mehr benötigt, würde ich sie abkaufen




Ich verwende 433MHz Module für den 868MHz GFSK Empfang.
Kann dies der Grund sein, warum ich mit  GFSK nichts empfange. Lässt sich ungefähr abschätzen wie gross die Dämpfung durch die Fehlanpassung am Antenneneingang ist?

bei 0x12:MDMCFG2– Modem Configuration
steht bei  SYNC_MODE[2:0]
Seting 4 (100):  No preamble/sync, carrier-sense above threshold

Was ist "carrier-sense above threshold"? Lässt sich der threshold einstellen?


Ich habe eine HomeMatic Steckdose HM-LC-Sw1-Pl-DN-R1,
weiss jemand wie ich den cc1101 konfigurieren muss, damit ich Homematic empfangen kann?
Ist eine Entfernung von ca 2m ok, oder ist dies wegen dem 433MHz Modul schon zu weit?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

HomeAuto_User

Zitat von: Ralf9 am 26 Dezember 2019, 13:10:42
Ich verwende 433MHz Module für den 868MHz GFSK Empfang.
Kann dies der Grund sein, warum ich mit  GFSK nichts empfange. Lässt sich ungefähr abschätzen wie gross die Dämpfung durch die Fehlanpassung am Antenneneingang ist?

bei 0x12:MDMCFG2– Modem Configuration
steht bei  SYNC_MODE[2:0]
Seting 4 (100):  No preamble/sync, carrier-sense above threshold

Was ist "carrier-sense above threshold"? Lässt sich der threshold einstellen?


Ich habe eine HomeMatic Steckdose HM-LC-Sw1-Pl-DN-R1,
weiss jemand wie ich den cc1101 konfigurieren muss, damit ich Homematic empfangen kann?
Ist eine Entfernung von ca 2m ok, oder ist dies wegen dem 433MHz Modul schon zu weit?

Gruß Ralf

@Ralf9, vielleicht findest du hier einen Ansatz https://github.com/jp112sdl/Beispiel_AskSinPP


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

plin

Hi Ralf,

ich habe bei mir zu Hause Homematic-Geräte im Einsatz und nutze einen Original-CUL. Meine SDUINOs haben auch die jeweils passenden CC1101er im Einsatz, deshalb fehlen mir die Erfahrungswerte, um auf Deine Frage die passenden Antworten zu haben.

Hast Du einen SDR-Stick? Dann könntest Du zumindest OOK auf 868 MHz senden und schauen wie sich 433 vs 868 MHz und die Entfernung SDUINO/SDR-Stick auswirkten.

VG plin
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Ralf9

Zitat@Ralf9, vielleicht findest du hier einen Ansatz https://github.com/jp112sdl/Beispiel_AskSinPP
@HomeAuto_User, Danke dort habe ich die Konfiguration für Homematic gefunden.

ZitatHast Du einen SDR-Stick? Dann könntest Du zumindest OOK auf 868 MHz senden und schauen wie sich 433 vs 868 MHz und die Entfernung SDUINO/SDR-Stick auswirkten.
Nein, ich habe keinen SDR-Stick
OOK auf 868 MHz funktioniert zwischen minicul und nanocul bei 1m Abstand problemlos, habe aber nicht auf die RSSI geachtet.

Gruß Ralf

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

@HomeAuto_User:
ZitatHallo, sorry das ich nun Zwischenfrage. Ich werde das Gefühl nicht los, Ihr wisst nicht 100% auf welcher Modulation das von Euch gewollte stattfindet. Ich lese immer nur, step zu der Variante und zu dieser...

Ja, da hast Du schon recht. Unser Problem ist, dass wir alle eine andere HW- und Firmware Basis nutzen.
Ausserdem haben wir in 3 Threads "Paralleldiskussionen", ich bin mir nicht mehr ganz sicher wo welche Diskussion läuft.

Mein Ansatz war, dass wir über meine Kopp Firmware gehen könnten, da ich hier schon beliebige Botschaften mit GFSK empfangen kann.
Die Kopp Firmware läuft stabil und ich kenne mich damit aus  :).
Allerdings arbeite ich immer direkt mit einem Terminalprogramm (Tera Term, Windows10), dann kann ich mir sicher sein, dass ich alle Antworten des Sticks auch sehe ohne das FHEM etwas rausfiltert.

@Ralf9:
bzgl. den 433Mhz Modulen, mit diesen hier:
https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476
habe ich extrem schlechte Erfahrung gemacht, da die Frequenz völlig daneben lag.

Mir persönlich wäre am liebsten wir könnten weitermachen wie hier beschrieben:
https://forum.fhem.de/index.php/topic,82379.msg1005476.html#msg1005476
Wenn wir die Module mit Kopp zum Laufen bekommen, können wir im nächsten Schritt den Signalduiono mit GFSK zum laufen bekommen und danach
auf 2-FSK umstellen (falls nötig). die Kopp FW sendet via Fifo definierte Botschaften, die wir dann auf der Gegenseite analysieren können.

Als ersten Schritt müssen wir aber dafür sorgen, dass sich die Sender- und Empfänger Hardware verstehen um auszuschliessen, dass irgend etwas an der HW nicht funktioniert

Ich hätte heute Abend etwas Zeit
RaspII

plin

#44
Leichte Euphorie: ich habe sowohl den Rolladen 1 (bisher relativ zuverlässig) als auch den Rolladen 2 (ging bisher so gut wie nie) mittels FSK zu einer Abwärtsbewegung überreden können, und das mit der ersten halbwegs passenden frisch mitgeschnittenen Sequenz.

Wo soll ich anfangen?

Ich bin bei der durch den Vergleich RIO-FB vs. SDUINO ermittelten Frequenz von 868.302 MHz sowie dem Hub von 58 kHz geblieben.

ccconf: freq:868.302MHz bWidth:58KHz rAmpl:42dB sens:8dB (DataRate:24795.53Baud, Modulation:GFSK)

Dann kamen die diversen Überlegungen zur Baudrate. Mein URH geht ja mit 1 MHz ans Sampling ran. Die Taktung der von mir gemessenen Code-Sequenzen liegt im Mittel bei 402 ms. Wenn ich die einzelnen Passagen der Codesequenz anhand von 400 ms tics bewerte und aufaddiere, komme ich auf 168 Einheiten. Dafür gehen in Summe 67.664 ms drauf. Eine Einheit dauert folglich 402,8 ms. Das entspricht dann den 2.482,9 Baud.

Dann kam mal wieder die Grundsatzfrage, ob ich den Sender auf diese Baudrate einstellen muss. Beim Empfang ermittelt der SDUINO ja die absoluten Zeitscheiben, unabhändig von der Baudrate. Wenn nun beim Empfang das Oversampling funktioniert, wieso dann nicht auch beim Senden? So habe ich mich für das 10fach Oversampling entschieden und überlasse das Status-Management 0/1 dem SDUINO. Die Mitschnitte im URH sehen vergleichbar aus. Der mittlere ist übrigens 2-FSK, der uneter GFSK. Peak weisen beiden auf. Da hätte ich bei GFSK etwas glattere Übergänge erwartet.

Und das scheint zu funktionieren. Die von der RIO-FB gesendeten Sequenzen wiederholen sich, leicht erkennbar an der Anfangssequenz 0121212121212121212121213.

mySIGNALduino: Read, msg READredu: MU;P0=-15610;P1=403;P2=-408;P3=-4014;P4=-810;P5=803;D=0121212121212121212121213141414525252141452145214521452521414141414145214141414521452145214525252525252521452525214521414521452521452525252525252525214141<ende>0121212121212121212121213141414525252141452145214521452521414141414145214141414521452145214525252525;CP=1;R=63;O;

Bei meinen OOK-Versuchen musste ich die mitgeschnittenen Sequenzen durchtesten, um brauchbare zu finden. Heute habe ich zwei optisch brauchbar aussehende genommen und damit direkt Erfolg gehabt.

ccregAll:

ccreg 00: 0D 2E 2D 47 D3 91 3D 04 32 00 00 06 00 21 65 6F
ccreg 10: F9 F4 18 23 B9 40 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2D 12 1F 41 00 59 7F 3F 88 31 0B

Configuration Register Detail (address, name, value):
0x00 IOCFG2   - 0x0D
0x01 IOCFG1   - 0x2E
0x02 IOCFG0   - 0x2D
0x03 FIFOTHR  - 0x47
0x04 SYNC1    - 0xD3
0x05 SYNC0    - 0x91
0x06 PKTLEN   - 0x3D
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32
0x09 ADDR     - 0x00
0x0A CHANNR   - 0x00
0x0B FSCTRL1  - 0x06
0x0C FSCTRL0  - 0x00
0x0D FREQ2    - 0x21
0x0E FREQ1    - 0x65
0x0F FREQ0    - 0x6F
0x10 MDMCFG4  - 0xF9
0x11 MDMCFG3  - 0xF4
0x12 MDMCFG2  - 0x18
0x13 MDMCFG1  - 0x23
0x14 MDMCFG0  - 0xB9
0x15 DEVIATN  - 0x40
0x16 MCSM2    - 0x07
0x17 MCSM1    - 0x00
0x18 MCSM0    - 0x18
0x19 FOCCFG   - 0x14
0x1A BSCFG    - 0x6C
0x1B AGCCTRL2 - 0x07
0x1C AGCCTRL1 - 0x00
0x1D AGCCTRL0 - 0x91
0x1E WOREVT1  - 0x87
0x1F WOREVT0  - 0x6B
0x20 WORCTRL  - 0xF8
0x21 FREND1   - 0x56
0x22 FREND0   - 0x11
0x23 FSCAL3   - 0xEF
0x24 FSCAL2   - 0x2D
0x25 FSCAL1   - 0x12
0x26 FSCAL0   - 0x1F
0x27 RCCTRL1  - 0x41
0x28 RCCTRL0  - 0x00
0x29 FSTEST   - 0x59
0x2A PTEST    - 0x7F
0x2B AGCTEST  - 0x3F
0x2C TEST2    - 0x88
0x2D TEST1    - 0x31
0x2E TEST0    - 0x0B


Jetzt muss meine Frau nur noch eine Freunding besuchen, damit ich alle Rolläden durchspielen und die Codes mitschneiden kann (das ständige rauf/runterfahren hat sie letztes Jahr ziemlich genervt  ;D).

P.S. 6 Rolläden, je up/stop/down bedeutet in Summe 18 Codesequenzen. Wenn das funktioniert sollte der Ansatz ausbaufähig sein.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB