unbekanntes Funkprotokoll Eberle Instat 868-r1

[Ralf9]

Wie siehts mit der DEVIATN aus? Hast Du die ermittelt oder durch probieren herausgefunden?

Was wäre denn der nächste Schritt um das Device U218 "richtig" einzubinden? Sprich, dass es zB wie ein Funkschalter dargestellt wird. Also mit den Werten "Identnummer des Senders", Status, Zähler und CRC.

Es fehlt noch die Bedeutung vom Status Nibble. Hast Du geschaut ob dies immer die gleichen Werte sind oder ob da noch was anderers drin stecken könnte?
Ich kann nicht erkennen, daß da eine Prüfsumme drin steckt.

[DerD]

Deviation ist abgeglichen zwischen Sender und CC1101 per SDR-RTL und Waterfalldiagramm. Da sehe ich kein Potential.

zu den Bedeutungen der Nibbles hier. Ausgeben kann man die Prüfsumme schon, die finale Verifizierung des Algorithmus steht aber noch aus. Immer wieder hatte ich da Unstimmigkeiten, was aber auch von der Dekodierung gekommen sein mag. Und der CRC zu Recht nicht gepasst hat.

...

Hier die examplarische Auswertung, um aus den Bits/Nibbles sinnvolle Werte zu erhalten. Jedes Nibble beginnt mit dem niedrigstwertigen Bit.

Code Auswählen Erweitern

2026.04.20 14:32:48 4:U218#82C7BE_1000001011000111101111100 (1) => Slicen in 6 Nibbles
U218#82C7BE_1 0000 0101 1000 1111 0111 1100 => Invertierung
              1111 1010 0111 0000 1000 0011
              F    5    E    0    1    C
&E5F => 3920, entspricht 4-stelligen Codenummer des Senders

Nibble 4:
A: Learn
9: Reset
7: on
0: off => korrekt

Nibble 5:
Counter: 1000 => 1
14:42:   0100 => 2 korrekt
14:52:   1100 => 3 korrekt

CRC/Validity Check: (Sum Nibble 1-6) Mod 15 = 5
=> muss noch überprüft werden ob korrekt

bzw ausführlicher:

...

Code Auswählen Erweitern

...

 xxxx  xxxx  xxxx  xxxx  xxxx  xxxx
 0123  0123  0123  0123  0123  0123

  ||    ||    ||    ||    ||    ||
  ||    ||    ||    ||    ||    ||
  ||    ||    ||    ||    ||    ||
  ||    ||    ||    ||    ||    \/
  ||    ||    ||    ||    ||   Prüfcode 0-F
  ||    ||    ||    ||    ||
  ||    ||    ||    ||    \/
  ||    ||    ||    ||   Zähler 0-F
  ||    ||    ||    ||
  ||    ||    ||    \/
  ||    ||    ||   Actioncode 0-F
  ||    ||    \/
  ||    ||    ID2, 0-F, zufällige Änderung bei jedem Lernen
  ||    ||
  ||    \/             
  ||    ID1, 0-F, zufällige Änderung bei jedem Lernen
  ||   
  \/             
 ID0, 0-F, zufällige Änderung bei jedem Lernen


Actioncodes:
A: Lernen
9: Reset
7: An
0: Aus

Zähler:
einfaches Hochzählen um "1" für jede Aktion
Ausnahme: bei Actionscode "A" bleibt Zähler konstant

Prüfcode:
Berechnung: 15 - ((Summe Nibbles 1-5) mod 15)
Validity Check: Summe Nibbles 1-6 mod 15 = 15

Lernen:
xxx81x, gesendet im 6 Sekunden Takt

Reset: Sequenz des Actioncodes
9/0/7/0/7/0/7/0/0

xxx91x
xxx02x
xxx73x
xxx04x
etc.



[Ralf9]

Nibble 4:
A: Learn
9: Reset
7: on
0: off => korrekt

Bei den Nachrichten vom 2026.04.11 gibts auch Nibble 4: 1
z.B.

Code Auswählen Erweitern

2026.04.11 06:40:14 MU;P0=282;P1=-169;P2=761;P3=-1026;P4=-679;P5=-317;P6=421;P7=-129;CP=6;R=179;D=23242424256425656565642465246565652467010;e;
U218#04E193_000000100111100010011100_(24)
04E166
04E175
04E184
04E193
04E0A3
04E0B2

Kannst Du bitte auch mal posten wie die Nachrichten aussehen, wenn es von off nach on wechselt?

Hast Du inzwischen überprüft ob Deine berechnung der Prüfsumme passt?

[DerD]

Guter Hinweis mit dem Wert "1" bei Nibble 4. Das ist wohl ein Status den ich bisher nicht aktiv generieren konnte und dessen Bedeutung mir derzeit auch nicht bekannt ist. Es scheint aber korrekt zu sein, die Checksumme berücksichtigt die Änderung um 1 ja.

Code Auswählen Erweitern

2026.05.03 08:34:41 4: MySignalPicoLAN/msg READ: ␂MU;P0=343;P1=-764;P2=-4954;P3=2491;P4=-2546;P5=688;P6=-1138;P7=-394;CP=0;R=19;D=23456570157015707070107070707075701510757010;e;␃
2026.05.03 08:34:41 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:34:41 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110100110101010010101010101101001100101101001 (48)
2026.05.03 08:34:41 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#9CD715_100100111011111010001010_(24) length 1 RSSI = -64.5
2026.05.03 08:34:41 4: MySignalPicoLAN: equalDMS U218#9CD715_100100111011111010001010_(24) (1)
2026.05.03 08:34:41 4: MySignalPicoLAN Dispatch: U218#9CD715_100100111011111010001010_(24), Dropped (1) due to short time and equal msg
2026.05.03 08:34:57 4: MySignalPicoLAN/msg READ: ␂MU;P0=-1299;P1=-398;P2=336;P3=-775;P5=2469;P6=-2556;P7=673;CP=2;R=30;D=567071237123712121232121737371237121232120;e;␃
2026.05.03 08:34:57 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:34:57 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110100110101010010101100110011010011010100101 (48)
2026.05.03 08:34:57 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#9CD02B_100100111011000001001101_(24) length 1 RSSI = -59
2026.05.03 08:34:57 4: MySignalPicoLAN: equalDMS U218#9CD02B_100100111011000001001101_(24) (1)
2026.05.03 08:35:00 4: MySignalPicoLAN/msg READ: ␂MU;P0=328;P1=2454;P2=-2614;P3=659;P4=-1226;P5=-406;P6=244;P7=-797;CP=0;R=31;D=12343567373507050537050505053565070505370504;e;␃
2026.05.03 08:35:00 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:00 4: MySignalPicoLAN/msg READ: ␂MU;P0=329;P1=-797;P2=-4616;P3=2468;P4=-2591;P5=662;P6=-1143;P7=-390;CP=0;R=37;D=234565701515701070751070707075707010707510707;e;␃
2026.05.03 08:35:00 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:00 4: MySignalPicoLAN: EberleInstat, rawbitmsg=01001100110100101011001010101011010100101011001010 (50)
2026.05.03 08:35:00 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A97B9_1000010110011110110110011_(25) length 1 RSSI = -55.5
2026.05.03 08:35:00 4: MySignalPicoLAN: equalDMS U218#1A97B9_1000010110011110110110011_(25) (1)
2026.05.03 08:35:29 4: MySignalPicoLAN/msg READ: ␂MU;P0=-4435;P1=2458;P2=-2583;P3=649;P4=-1138;P5=-407;P6=312;P7=-780;CP=6;R=37;D=0123435673735676565376537373765656565656567;e;␃
2026.05.03 08:35:29 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:29 4: MySignalPicoLAN: EberleInstat, rawbitmsg=010011001101001010110010110011001100101010101010100 (50)
2026.05.03 08:35:29 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A90CF_1000010110010000001111111_(25) length 1 RSSI = -55.5
2026.05.03 08:35:29 4: MySignalPicoLAN: equalDMS U218#1A90CF_1000010110010000001111111_(25) (1)
2026.05.03 08:35:30 4: MySignalPicoLAN/msg READ: ␂MU;P0=-4643;P1=2474;P2=-2627;P3=650;P4=-1133;P5=-406;P6=344;P7=-792;CP=6;R=29;D=0123435673735676565376537373765656565656562;e;␃
2026.05.03 08:35:30 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.03 08:35:30 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0100110011010010101100101100110011001010101010101 (48)
2026.05.03 08:35:30 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#1A90CF_100001011001000000111111_(24) length 1 RSSI = -59.5
2026.05.03 08:35:30 4: MySignalPicoLAN: equalDMS U218#1A90CF_100001011001000000111111_(24) (1)
2026.05.03 08:35:33 4: MySignalPicoLAN/keepalive ok, retry = 0

Manuell bzw. automatisch an/aus wechselt 7/0 auf Nibble 4.

Die Verifizierung der Prüfsummenberechnung steht tatsächlich noch aus. Es klemmt daran, dass ich aus den unendlich langen log-files die entsprechenden patterns mit 'U218' nicht automatisiert rausbekomme, so dass ich eine gescheite und möglichst umfassende Wertebasis habe.
Deshalb war hier meine Idee, für jeden Sender ein jeweiliges Device automatisiert zu erstellen und die ausgelesenen Nibblewerte in entsprechende log-files zu plotten. Ist aber daran gescheitert, dass ich es auch zusammen mit GPT nicht geschafft habe, ein passendes instat.pm zu erstellen und korrekt einzubinden 

[Ralf9]

Die Verifizierung der Prüfsummenberechnung steht tatsächlich noch aus. Es klemmt daran, dass ich aus den unendlich langen log-files die entsprechenden patterns mit 'U218' nicht automatisiert rausbekomme, so dass ich eine gescheite und möglichst umfassende Wertebasis habe.

Es werden events erzeugt, die können mit einem notify ausgewertet werden.
z.B.

Code Auswählen Erweitern

define instatNot notify MySignalPicoLAN:DMSG.*U218.* {\\
my $e = $EVENT;;\\
my (undef, $d) = split('#', $e);;\\
my ($dd, undef, $dl) = split('_', $d);;\\
Log 2, ('test---test ' . $dd . ' ' . $dl)}

[DerD]

Die Prüfsumme ist bestimmt, anhand der gewonnenen Liste konnte das schnell bestimmt werden (im Gegensatz zu fhem kann GPT das sehr gut): das Komplement zu 0xF (15) der Nibble-Summe.

Checksum=(0xF−(∑Nibblesmod16))mod16

Beispiel: 04E01C

Nibbles: 0, 4, E(14), 0, 1
Summe: 0+4+14+0+1=19
19mod16=3
0xF−3=12=C ✅

Beispiel: 04E02B

Summe: 0+4+14+0+2=20
20mod16=4
0xF−4=11=B ✅

89B71B:

Nibbles (ohne Checksumme): 8, 9, B(11), 7, 1
Summe: 8+9+11+7+1=36
36mod16=4
0xF−4=11=B

Interpretation:
Das ist eine einfache 4-Bit One's-Complement Checksumme über die Nibbles, so gewählt, dass gilt:

(Summe aller 6 Nibbles)mod16=0xF

Was den Wert von Nibble4 mit "1" angeht, habe ich die Vermutung, dass da vielleicht ein Battery-Low gesendet wird, auch wenn der Empfänger (zumindest meiner) dafür keine Verwendung hat. Die Ventile bleiben auf "zu". Ist derzeit aber noch reine Spekulation. Habe ich bei 2 Sendern jetzt gesehen, und leider noch ohne Systematik. Nur einmal als Reihe, und davon hatte ich zufällig Werte zum hier posten erwischt.

Um ein jeweiliges Logfile für jeden Sender zu haben, habe ich mir mit sowas beholfen. Nicht schön und alle manuell angelegt. Aber sie tun zumindest mal was sie sollen.

Code Auswählen Erweitern

define log9CD FileLog ./log/log9CD-%Y.log MySignalPicoLAN:DMSG.*U218#9CD.*
#   CFGFN     
#   DEF        ./log/log9CD-%Y.log MySignalPicoLAN:DMSG.*U218#9CD.*
#   FD         19
#   FUUID      69f8c7fc-f33f-3e5d-3ea0-f9ef6e4863e3358f
#   NAME       log9CD
#   NOTIFYDEV  MySignalPicoLAN
#   NR         67
#   NTFY_ORDER 50-log9CD
#   REGEXP     MySignalPicoLAN:DMSG.*U218#9CD.*
#   STATE      active
#   TYPE       FileLog
#   currentlogfile ./log/log9CD-2026.log
#   logfile    ./log/log9CD-%Y.log
#   READINGS:
#     2026-05-04 19:08:01   linesInTheFile  1
#
setstate log9CD active
setstate log9CD 2026-05-04 19:08:01 linesInTheFile 1



[DerD]

Kleine Überraschung was den Statusnibble betrifft. Da gibt es mehr Varianten als ich bisher hatte, was mit den unterschiedlichen Sendern zu tun hat.
Was ich bisher wusste, VN0102 und VN0204 unterscheiden sich im Protokoll und Frequenzshift. Dann gibt Sender analog und mit digitalem Display. Die digitalen haben Protokoll und Frequenzshift wie VN0204. Also dachte ich, der Rest ist auch gleich. Nix da, jetzt sehe ich nämlich, dass die andere Statuswerte schicken:

VN0204 VN0102 Analog "ein": 7
VN0204 VN0102 Analog "aus": 0
Rev 2.6 digital "ein": 1
Rev 2.6 digital "aus" 0-5K: 0
Rev 2.6 digital "aus" 5-10K: 4
Rev 2.6 digital "aus" >10K: 2

Also in Abhängigkeit Soll/Isttemperatur gibt es verschiedene "aus" Modi. Einen weiteren "An"-Modus zusätzlich zu "1" habe ich noch nicht gefunden, auch wenn Soll >5K über Ist.
Mehr wie "Aus" können meine Aktoren aber auch nicht. Kann sein, dass da auch Klimaanlagensteuerung möglich ist, was ich nicht habe.
Bei den analogen dreht sich im Kühl- statt Heizbetrieb "ein" und "aus" einfach um, also "0" statt "7" und umgekehrt.



Was die Demodulation angeht, da gibt es noch Protokolle die durchrutschen. Hier zB die ersten beiden, der dritte klappt dann, ist aber dennoch nicht vollständig. Hast du eine Ideen warum? Protokolle mit weniger RSSI werden dagegen korrekt demoduliert.

Code Auswählen Erweitern

2026.05.05 13:12:01 4: MySignalPicoLAN/msg READ: ␂MU;P0=485;P1=2449;P2=-2637;P3=644;P4=-1082;P5=-451;P6=275;P7=-796;CP=6;R=5;D=123435656567373765653737376565656535656704;e;␃
2026.05.05 13:12:01 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:01 4: MySignalPicoLAN/msg READ: ␂MU;P0=225;P1=-293;P2=-2614;P3=649;P4=-1188;P5=-476;P6=318;P7=-806;CP=6;R=211;D=23435656567373765653737376565656535050761;e;␃
2026.05.05 13:12:01 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:02 4: MySignalPicoLAN/msg READ: ␂MU;P0=225;P1=2444;P2=-2602;P3=648;P4=-1086;P5=-477;P6=301;P7=-803;CP=6;R=220;D=123435656567373765653737376565656535050764;e;␃
2026.05.05 13:12:02 4: MySignalPicoLAN: Fingerprint for MU Protocol id 218 -> Eberle Instat r1 matches, trying to demodulate
2026.05.05 13:12:02 4: MySignalPicoLAN: EberleInstat, rawbitmsg=0101010011001100101011001100110010101010110 (42)
2026.05.05 13:12:02 4: MySignalPicoLAN: decoded matched MU Protocol id 218 dmsg U218#7030F_111000001100000011110_(21) length 1 RSSI = -92
2026.05.05 13:12:02 4: MySignalPicoLAN: equalDMS U218#7030F_111000001100000011110_(21) (1)


[Ralf9]

Was die Demodulation angeht, da gibt es noch Protokolle die durchrutschen. Hier zB die ersten beiden, der dritte klappt dann, ist aber dennoch nicht vollständig. Hast du eine Ideen warum? Protokolle mit weniger RSSI werden dagegen korrekt demoduliert.

Das erste und zweite wird bei mir als id 218.1 erkannt.
Bei der zweiten und dritten haben am Ende 2 Pulszeiten nicht gepasst, habe 0 durch 6 ersetzt, dann hats gepasst

Code Auswählen Erweitern

MU;P0=485;P1=2449;P2=-2637;P3=644;P4=-1082;P5=-451;P6=275;P7=-796;CP=6;R=5;D=123435656567373765653737376565656535656704;e;
 decoded matched MU Protocol id 218.1 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -71.5

MU;P0=225;P1=-293;P2=-2614;P3=649;P4=-1188;P5=-476;P6=318;P7=-806;CP=6;R=211;D=23435656567373765653737376565656535656761;e;
 decoded matched MU Protocol id 218.1 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -96.5

MU;P0=225;P1=2444;P2=-2602;P3=648;P4=-1086;P5=-477;P6=301;P7=-803;CP=6;R=220;D=123435656567373765653737376565656535050764;e;
 decoded matched MU Protocol id 218 dmsg U218#7030F6_111000001100000011110110_(24) length 1 RSSI = -92

[DerD]

Bei der zweiten und dritten haben am Ende 2 Pulszeiten nicht gepasst, habe 0 durch 6 ersetzt, dann hats gepasst

So ganz habe ich das nicht kapiert was du damit sagst. War das eine manuelle Anpassung der Streamdaten oder der Auswerteparameter? Bei ersterem wäre für die Routine außer Enpfangsverbesserung ja nichts möglich, oder?

Ich hatte für den 218.1 nie eine Erkennung gehabt, deshalb aus der whitelist genommen.
Der 703-Sender wird im Regelfalll auch von 218 erkannt. Nur in den Einzelfällen nicht, wie den obigen. Kann man da nicht was anpassen, dass es die auch erkennt?
Da wollte ich eh mal fragen warum es den überhaupt gibt. Die Parameter sind nämlich auch etwas seltsam, short low fast so lang wie long high.

Code Auswählen Erweitern

        zero            => [-2.1],   # -500 short low
        one             => [1],      #  235 short high
        two             => [-3.6],   # -840 long  low
        float           => [2.5],    #  580 long  high


Ergänzung:

Code Auswählen Erweitern

cmdBank:
A: b=0 freq:868.965MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:4004.48Baud) [boffs=0000]

   ccmode=0 sync=D391 Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:14.282kHz

Code Auswählen Erweitern

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 21 6B F6
ccreg 10: 57 43 00 23 B9 31 07 00 18 14 6C 07 00 90 87 6B
ccreg 20: F8 56 11 ED 2D 14 11 41 00 59 7F 3F 88 31 0B

cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2   - 0x0D [29]
0x01 IOCFG1   - 0x2E
0x02 IOCFG0   - 0x2D [3F]
0x03 FIFOTHR  - 0x07
0x04 SYNC1    - 0xD3
0x05 SYNC0    - 0x91
0x06 PKTLEN   - 0x3D [0F]
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x32 [45]
0x09 ADDR     - 0x00
0x0A CHANNR   - 0x00
0x0B FSCTRL1  - 0x06 [0F]
0x0C FSCTRL0  - 0x00
0x0D FREQ2    - 0x21 (10) [1E]
0x0E FREQ1    - 0x6B (B0) [C4]
0x0F FREQ0    - 0xF6 (71) [EC]
0x10 MDMCFG4  - 0x57 [8C]
0x11 MDMCFG3  - 0x43 (C4) [22]
0x12 MDMCFG2  - 0x00 (30) [02]
0x13 MDMCFG1  - 0x23 [22]
0x14 MDMCFG0  - 0xB9 [F8]
0x15 DEVIATN  - 0x31 (00) [47]
0x16 MCSM2    - 0x07
0x17 MCSM1    - 0x00 [30]
0x18 MCSM0    - 0x18 [04]
0x19 FOCCFG   - 0x14 [36]
0x1A BSCFG    - 0x6C
0x1B AGCCTRL2 - 0x07 [03]
0x1C AGCCTRL1 - 0x00 [40]
0x1D AGCCTRL0 - 0x90 [91]
0x1E WOREVT1  - 0x87
0x1F WOREVT0  - 0x6B
0x20 WORCTRL  - 0xF8
0x21 FREND1   - 0x56
0x22 FREND0   - 0x11 [16]
0x23 FSCAL3   - 0xED (E9) [A9]
0x24 FSCAL2   - 0x2D (2A) [0A]
0x25 FSCAL1   - 0x14 (00) [20]
0x26 FSCAL0   - 0x11 (1F) [0D]
0x27 RCCTRL1  - 0x41
0x28 RCCTRL0  - 0x00
0x29 FSTEST   - 0x59
0x2A PTEST    - 0x7F
0x2B AGCTEST  - 0x3F
0x2C TEST2    - 0x88
0x2D TEST1    - 0x31
0x2E TEST0    - 0x0B


[Ralf9]

So ganz habe ich das nicht kapiert was du damit sagst. War das eine manuelle Anpassung der Streamdaten oder der Auswerteparameter?

Das war eine manuelle Anpassung der Streamdaten, da bleibt nur eine Empfangsverbesserung.

Da wollte ich eh mal fragen warum es den überhaupt gibt. Die Parameter sind nämlich auch etwas seltsam, short low fast so lang wie long high.

Die id 218.1 gibts damit auch diese MU Nachrichten mit den seltsamen Pulszeiten erkannt werden.

Hier ist der rfmode, eingelesen wird er mit "get raw"

Code Auswählen Erweitern

CW000D,022D,0307,04D3,0591,063D,0704,0832,0D21,0E6B,0FF6,1057,1143,1200,1323,14B9,1531,1700,1818,1914,1B07,1C00,1D90,23E9,242A,2500,2611,3D00,3E00,4045,4162,4249,436E,4473,4574,4661,4774
Mir sind dabei 2 cc Register aufgefallen:
0x1B AGCCTRL2 - 0x07 , -> bei fast allen anderen rfmode ist es 0x43
0x1D AGCCTRL0 - 0x90 , -> bei fast allen anderen rfmode ist es 0x91