unbekanntes Funkprotokoll Eberle Instat 868-r1

[DerD]

Ein herzliches Hallo in die Runde,

ich habe im Bestand des Hauses eine Raumtemperatursteuerung von Eberle Typ Instat 868-r1. Leider findet sich in den Weiten des Netzes dazu nicht detailliertes, am passendsten waren noch 2 Themen hier, aber leider auch ohne Ergebnis.
Ziel ist ganz klar das Protokoll zu dekodieren und verwenden zu können.
Was ich bisher weiß, auch mit Hilfe des Wikis "Unbekannte Protokolle" hier und einem RTL-SDR mit URH :
868MHz, 2-FSK
Ein Protokoll mit 82 Bit hat die Form

Code Auswählen Erweitern

0000000000001111111000000011000110011001010110101001100110101010011001010101010110

davon ist sind 34 Bit Präambel bzw Sync:

Code Auswählen Erweitern

0000000000001111111000000011000110

Der folgende Teil

Code Auswählen Erweitern

011001010110101001100110101010011001010101010110
ist mit ziemlicher Sicherheit Manchester-codiert. Decodierung verkürzt in dem Fall nur die Codelänge, hat mich aber bisher nicht weitergebracht, deshalb folgend immer in codierter Form:

Es kommen dann
- 24Bit für die Senderadresse
- 8 Bit für den Status des Thermostaten An/Aus
- 16 Bit mit unbekannter Verwendung

Nehme ich den mitgeschnittenen Rohdatencode für "An" bzw. "Aus" und sende über einen CC1101, kann ich das Ventil gezielt an- und ausschalten.

Und nun kommen die ungelösten Probleme, zuerst die letzten 16 bit: diese ändern sich, und wiederholen sich alle 16 Sendungen, sind aber bei verschiedenen Sendern nicht dieselben. Sende ich ohne einen Wechsel, geht der Empfänger auf Störung. Hat jemand eine Idee, weshalb diese Wechsel überhaupt nötig sind? Abschluß mit Paritätsbit kann ich ausschließen.

Dann der Code für An/Aus: der unterscheidet sich bei verschiedenen Sendern auch nach der Manchester-Decodierung, also "An" kann dann sein 1110 oder 0001.

Die Senderadresse wird für jedes Anlernen Sender/Empfänger immer wieder neu vergeben, da versuche ich derzeit herauszufinden was alles möglich sind, oder ob es da bestimmte Muster gibt.

Mit dem derzeitigen Stand kann ich lediglich wie ein Papagei nur bestehende Protokolle nachsprechen, muss also diese erst einmal mit einem Sender erzeugen und mitschneiden.

Leider habe ich auch kaum Erfahrung in dem Bereich, eventuell hat aber der ein oder andere hier ein paar Tips um dabei weiterzukommen.

Gruß,
Dieter

[rudolfkoenig]

die letzten 16 bit: diese ändern sich, und wiederholen sich alle 16 Sendungen, sind aber bei verschiedenen Sendern nicht dieselben. Sende ich ohne einen Wechsel, geht der Empfänger auf Störung.

Rolling-Code + CRC?

Meiner Erfahrung nach lohnt sich laenger nach Doku zu suchen.
Auch Beschreibungen von aehnlichen Geraeten vom gleichen Hersteller koennen als Ideengeber herhalten.
Und der Hersteller des Geraetes muss nicht gleich Hersteller des Protokolls sein.

Uebrigens: alle Achtung, ich kann mich an viele vergleichbare Sessions mit Kopfschmerzen danach erinnern

[KölnSolar]

2.Post und dann sowas. Da kann ich Rudi nur zustimmen.

Meiner Erfahrung nach lohnt sich laenger nach Doku zu suchen.

Und auch da stimme ich ihm zu. Wenn man ein paar mehr Infos zum Funkprotokoll(Frequenz, Datenrate...) hat, kann man einen Abgleich mit der signalduino_protocols machen und vielleicht ist das Protokoll bereits vorhanden.

Grüße Markus

[DerD]

Das Protokoll hardcoremäßig zu zerlegen mache ich ja nur, weil ich nichts gefunden habe. Ich meine nach intensiver Suche. Mögliche Ähnlichkeiten waren bisher leider alles nichts.
Heißt das file komplett signalduino_protocols.pm?
Frequenz, Signallängen/Datenrate habe ich ja alles in der Zwischenzeit ausgelesen.

Leider gibt der Sender auch nach zerlegen nicht mehr Infos Preis, dass ein anderer Hersteller dahinterstecken könnte. Habe neben den bei mir aktiven jetzt noch Ersatz bekommen, älteren Datums, gleiche Beschriftung, unterschiedliche Hardware. Und leider auch unterschiedliches Protokoll. Aber da laufen die Tests noch.

Kein Rolling Code, soweit sicher. Der ist komplizierter. Und wiederholt sich auch nicht - zumindest nicht so schnell.

PS: das ist er zweite Winter an dem ich mich mit dem Teil beschäftige. Einfach ist doch langweilig

[KölnSolar]

Einfach ist doch langweilig

stimmt.

Heißt das file komplett signalduino_protocols.pm?

genau.
Und der Signalduino wäre auch genau die Hardware, die Du für die Anbindung an FHEM brauchst.

[DerD]

Kann es sein dass die Datei zwischenzeitlich "SD_ProtocolData.pm" heißt?
Die bin ich durch und habe auch speziell auf Thermostate geachtet, leider ohne Erfolg. Allein schon über die Tatsache, dass die ersten 3 Codes (0,1,2) bei mir später nicht mehr auftauchen, konnte man quasi alle bisher dokumentierten schon ausschließen.

Hier noch in SD-Notation:
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746 D=01234356567356565676565653565656765656565373565

Ich weiß, dass der Signalarduino die Hardware wäre, um es in FHEM einzubinden. Die Synology ist ja da, aber FHEM ohne eingehende Daten ist etwas öde Und zu steuern hat sie bisher auch nichts,

[Ralf9]

Es gibt

FSK_PCM:
- Es wird für RX und TX der FIFO des cc1101 verwendet.
- Damit der Begin der Nachricht erkannt wird muß ein SYNC angegeben werden.
- Es muß auch im FIFOTHR Reg ein threshold für den RX FIFO angegeben werden

und

FSK_PWM:
- es wird der asynchronous serial mode verwendet (RX: Data out GDO2, TX: GDO0)
- der cc1101 FIFO wird nicht verwendet

siehe
https://forum.fhem.de/index.php/topic,106594.msg1150650.html#msg1150650

P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746 D=01234356567356565676565653565656765656565373565

dies ist der asynchronous serial mode

Gruß Ralf

[DerD]

FSK-PCM und FSK-PWM und asynchron serial mode sind doch nur für Empfang bzw. Senden per CC1101 relevant oder?
Ich mache Signalanalyse derzeit nur per SDR und URH. Ein initialer Test mit versenden von Rohdaten per CC1101 aus der Arduino-IDE hatte nach Baudratenanpassung ja funktioniert. Wie gesagt, ein Signalarduino ist ja noch nicht in Betrieb, ich sehe derzeit aber auch noch keinen Vorteil ggüber SDR solange ich nicht sicher weiß, was für Daten da unterwegs sind. Und man weiß da nie genau, ob die Daten exakt stimmen oder ein Parameter nicht gestimmt hat und nur Kauderwelsch ankommt. Das Thema hatte ich schon mit der Wetterstation, seither immer per SDR.

Verbaut sind in den Thermostaten vermutlich TDA5100 bzw. TDK5100 als Sende-IC, habe mich aber nicht weiter damit beschäftigt weil die ja nur ausgeben was ihnen übermittelt wird.

Der verlinkte Thread ist interessant übrigens. Dauert aber noch bis ich komplett durch bin.

PS: habe mir zwischenzeitlich die Eigenschaft der Teile zu Nutze gemacht, beim Anlernen jedesmal eine neue ID zu erzeugen. Es muss noch durch ein paar Hirnwindungen, aber ich denke den Teil kann ich bald selber erzeugen.

[Ralf9]

FSK-PCM und FSK-PWM und asynchron serial mode sind doch nur für Empfang bzw. Senden per CC1101 relevant oder?

Ja

Und man weiß da nie genau, ob die Daten exakt stimmen oder ein Parameter nicht gestimmt hat und nur Kauderwelsch ankommt.

Ja, beim cc1101 muß z.B. die datarate recht genau passen. Einige der Parameter müssten sich evtl aus dem Datenblatt und der Beschaltung des Sende IC ermitteln lassen.
Wenn die Senderadresse und der Status des Thermostaten An/Aus immer gleich sind, sollten die Parameter eigentlich passen.

Beim signalduino wird direkt der decodierte Manchester Code ausgegeben

z.B. dies hier

Code Auswählen Erweitern

P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746;D=01234356567356565676565653565656765656565373565;
wird so ausgegeben

Code Auswählen Erweitern

MC;LL=-746;LH=736;SL=-378;SH=358;D=88787D0;C=369;L=26;s5;b5;

[DerD]

Das Protokoll beim Einlernen habe ich nun zu 95% geklärt. Diesmal nach Manchesterdecoding um Zahlenwerte zu erhalten:

12 Bit Sender ID, theoretisch 0-4095 (000 - FFF), die Praxis zeigt zwar mehr Werte in der Mitte als an den Rändern, Mittelwert ist 2079 - ich denke das passt
4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade -   ich denke das passt
8 Bit davon 4 Bit Verwendung noch unklar, bzw. im Widerspruch zum Thermostatbetrieb (da gibt es keine Korrelation zu An/aus). Hier Werte 0x5 oder 0xA, immer als C5 oder 3A in Abhängigkeit von An/Aus - ich denke das passt
         davon 4 Bit Verwendung noch unklar, vermutlich zufällig 0-15 (0-F), Werte 0 .. E sind bestätigt, allerdings ist der Mittelwert 5,5 und damit unterschiedlich zu Sollwert 7,5 - möglicherweise doch CRC oder andere Fehlerkorrektur

Leider kenne ich mich zu wenig in der Theorie der Fehlerkorrektur aus, um da etwas gezielt nachzuprüfen. Als Test werde ich nun mal einen Code erzeugen und zum einlernen verschicken. Und dann nochmals mit anderem Finale. Wenn er keinen nur einen nimmt, ist es wohl Fehlerkorrektur und ich habe zufällig richtig geraten. Nimmt er beide hat es eine andere Bedeutung oder eben keine bzw. ist noch nicht definiert.

Eine Frage: kann man per FHEM solch eine Logik implementieren? Also wenn ID ungerade, dann nächster Code "soundso"?

[DerD]

Code Auswählen Erweitern

MC;LL=-746;LH=736;SL=-378;SH=358;D=88787D0;C=369;L=26;s5;b5;

Danke, das verstehe ich zum Großteil, bzw. bis zum "C=". Gibt es da ein Tutorial dafür, bzw. wofür steht C,L,s5 und b5? 

[Ralf9]

Danke, das verstehe ich zum Großteil, bzw. bis zum "C=". Gibt es da ein Tutorial dafür, bzw. wofür steht C,L,s5 und b5? 

C ist die Clock
L ist die Länge in Bits

s und b sind debugausgaben
Eine Schwierigkeit beim Manchesterdecoding ist die richtige Flanke (pos oder neg) am Anfang zu finden, damit die dekodierte Nachricht nicht invertiert ist, da beim ersten Long mit der dekodierung angefangen wird, gelingt dies zuverlässig.

b sind die Anzahl der Pulse bis zum ersten Manchesterbit, dies ist die Länge der Präambel bzw Sync
s sind die Anzahl der Pulse bis zum ersten Long
wenn s und b gleich sind, ist das long am Anfang der Manchesternachricht

[DerD]

Hallo nochmals,

zwischenzeitlich bin ich bei der Dekodierung der Lerncodes etwas weiter gekommen, leider aber nur ein wenig und jetzt klemme ich ganz. ich bin mir sicher, dass die letzten 4 Bits eine Art Prüfsumme sind. Sende ich Code an den Empfänger, wird von den 16 Möglichkeiten immer nur genau eine akzeptiert. Leider konnte ich aber bisher keine allgemeine Systematik bestimmen, nur einzelne Regeln. CRC konnte ich ausschließen, es gibt ja aber fast beliebig viele Möglichkeiten so einen Prüfcode zu berechnen. Ich habe nun systematisch zu einigen IDs einen Prüfcode ermittelt, komme aber hier nicht weiter. Hat jemand noch eine Idee?

Regeln:
- der Prüfcode wird aus den 3 Werten der ID errechnet
- der Prüfcode ist nicht eindeutig für alle Werte eines Blocks/ID
- Wert und Komplementärwert zu 15 (ID3) haben gleichen Code (7/8; 6/9; 5/10; etc)
- bestimmte Bitfolgen ergeben gleichen Prüfcode, wie "0001" über alle 3 IDs, oder die verschobenen "11"er
- keine Regel aber auffällig: so gut wie alle Prüfcodes meiner Muster sind gerade, nicht ungerade. Bei zufälligen IDs war es nahezu 50/50

Irgendwie habe ich das Gefühl, etwas wichtiges übersehen zu haben. Jegliche Idee oder Theorie ist willkommen, ich habe die aktuell verfügbaren Werte mal unten angehängt. Auch kann ich jeglichen anderen Wert generieren um eine Theorie zu bestätigen oder auszuschließen. Mir fehlt zB noch jegliche Idee, wie der Prüfcode sich um "1" erhöhen oder verringern lässt. Aber möglicherweise ist das auch nicht relevant.

Gruß,
Dieter

Code Auswählen Erweitern


ID1  ID2  ID3   Code  ID1 ID2 ID3  Code

0000 0000 0001  1010  0x0 0x0 0x1  0xA
0000 0000 0010  0110  0x0 0x0 0x2  0x6
0000 0000 0011  1000  0x0 0x0 0x3  0x8
0000 0000 0100  0000  0x0 0x0 0x4  0x0
0000 0000 0101  1110  0x0 0x0 0x5  0xE
0000 0000 0110  0010  0x0 0x0 0x6  0x2
0000 0000 0111  1100  0x0 0x0 0x7  0xC
0000 0000 1000  1100  0x0 0x0 0x8  0xC
0000 0000 1001  0010  0x0 0x0 0x9  0x2
0000 0000 1010  1110  0x0 0x0 0xA  0xE
0000 0000 1011  0000  0x0 0x0 0xB  0x0
0000 0000 1100  1000  0x0 0x0 0xC  0x8
0000 0000 1101  0110  0x0 0x0 0xD  0x6
0000 0000 1110  1010  0x0 0x0 0xE  0xA
0000 0000 1111  1000  0x0 0x0 0xF  0x8

0000 0000 0001  1010  0x0 0x0 0x1  0xA
0000 0000 0010  0110  0x0 0x0 0x2  0x6
0000 0000 0100  0000  0x0 0x0 0x4  0x0
0000 0000 1000  1100  0x0 0x0 0x8  0xC
0000 0001 0000  1010  0x0 0x1 0x0  0xA
0000 0010 0000  0110  0x0 0x2 0x0  0x6
0000 0100 0000  0000  0x0 0x4 0x0  0x0
0000 1000 0000  1100  0x0 0x8 0x0  0xC
0001 0000 0000  1010  0x1 0x0 0x0  0xA
0010 0000 0000  0110  0x2 0x0 0x0  0x6
0100 0000 0000  0000  0x4 0x0 0x0  0x0
1000 0000 0000  1110  0x8 0x0 0x0  0xE ?Warum nicht "C"?

0000 0000 0011  1000  0x0 0x0 0x3  0x8
0000 0000 1100  1000  0x0 0x0 0xC  0x8
0000 0011 0000  1000  0x0 0x3 0x0  0x8
0000 1100 0000  1000  0x0 0xC 0x0  0x8
0011 0000 0000  1000  0x3 0x0 0x0  0x8

0000 0000 0110  0010  0x0 0x0 0x6  0x2
0000 0110 0000  0010  0x0 0x6 0x0  0x2
0001 1000 0000  0010  0x1 0x8 0x0  0x2
0110 0000 0000  0010  0x6 0x0 0x0  0x2

0100 0000 0010  0011  0x4 0x0 0x2  0x3 verstehe ich gar nicht?
0000 1111 0000  0011  0x0 0xF 0x0  0x3 verstehe ich gar nicht?


[Ralf9]

Mit den wenigen Infos ist es schwer zu helfen, Du hast bis jetzt nur Teile der Nachrichten gepostet.

12 Bit Sender ID, theoretisch 0-4095 (000 - FFF), die Praxis zeigt zwar mehr Werte in der Mitte als an den Rändern, Mittelwert ist 2079 - ich denke das passt
4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade -   ich denke das passt
8 Bit davon 4 Bit Verwendung noch unklar, bzw. im Widerspruch zum Thermostatbetrieb (da gibt es keine Korrelation zu An/aus). Hier Werte 0x5 oder 0xA, immer als C5 oder 3A in Abhängigkeit von An/Aus - ich denke das passt
         davon 4 Bit Verwendung noch unklar, vermutlich zufällig 0-15 (0-F), Werte 0 .. E sind bestätigt, allerdings ist der Mittelwert 5,5 und damit unterschiedlich zu Sollwert 7,5 - möglicherweise doch CRC oder andere Fehlerkorrektur

Demnach besteht die Nachricht nach der Manchester Dekodierung aus 24 Bit (6 Hexziffern)

Geht die Manchester Dekodierung der empfangenen Nachrichten inzwischen automatisch?

Sind die ID 1, ID 2, ID 3 die 12 Bit Sender ID? Wann ändert sich die ID?
Bleibt der 4 Bit Code bei gleicher Sender ID gleich?

Code Auswählen Erweitern


123456
IIISXY

III - Sender Id
S - 4 Bit An/Aus: 0xC oder 0x 3, "3" sofern ID ungerade, "C" wenn gerade -   ich denke das passt
X -
Y - Prüfcode?

Hast Du auch schon was zu X rausgefunden?


Kannst Du mal ca 20 - 50 der Hexnachrichten (6 Ziffern) posten? Mit verschiedenen und gleichen Sender Id, und An und Aus beschriften

Gruß Ralf

[DerD]

Hallo Ralf,
seither habe ich tatsächlich noch wesentliche Fortschritte gemacht, aktuell klemmt es tatsächlich erst einmal / nur noch an der Prüfsumme.

Ich habe über die Tage eine Vielzahl an Telegrammen mitgeschnitten und ausgewertet, alle der Einfachheit für das einlernen. Eine Vielzahl an Telegrammen habe ich mehrfach und sie sind dann identisch, also keine Art an rolling code an der Stelle. Insgesamt ~900 Möglichkeiten, nicht die Erwarteten ~4000 (FFF).  Manchesterdecodierung mache ich aktuell manuell per Excel.

Es sind immer Header (2Bit, nicht dargestellt) und 6 Nibbles, die Reihenfolge ist Original, die Gruppierung in ID1-3, Par1/2 und Prüfsumme von mir. Einen ersten Test für die Prüfsumme hatte ich mit reveng auf CRC gemacht, leider ohne Erfolg (no models found).

Fokussierung auf einfache ID-Werte, also "000" bis "00F". Bei diesen ergibt sich die Prüfsumme durch einfaches Xor von ID1-3, einem der beiden Par-Nibble und magicNumber "8".

Sobald aber einer der ID1/2 nicht mehr "0" ist, passt die Berechnung nicht mehr. Dass die MagicNumber insgesamt variiert wäre ja noch OK, aber besonders seltsam finde ich zB "FFx" bei der von "FF7" nach "FF8" bis "FFA" eine andere MagicNumber nötig wäre, und dann noch zwei weitere für den Rest.

Berechne ich die MN komplett aus ID1-3, Par und PS über alle Werte, ergeben sich eine Art von Muster, aber ohne dass ich darin eine Art an Systematik erkennen würde. Lediglich für Gerade und Ungerade aufeinander folgende IDs ist die MN aber immer dieselbe.

Die Liste aller Codes ist angehängt, keine Ahnung ob das Format so passend ist.

Gruß,
Dieter

Code Auswählen Erweitern


000 C5 4 001 3A A 002 C5 6 003 3A 8 004 C5 0 005 3A E 006 C5 2 007 3A C 008 C5 C 009 3A 2 00A C5 E 00B 3A 0 00C C5 8 00D 3A 6 00E C5 A 00F 3A 4
8A0 C5 4 8A1 3A A 8A2 C5 6 8A3 3A 8 8A4 C5 0 8A5 3A E 8A6 C5 2 8A7 3A C 8A8 C5 C 8A9 3A 2 8AA C5 E 8AB 3A 0 8AC C5 8 8AD 3A 6 8AE C5 A 8AF 3A 4
FF0 C5 4 FF1 3A A FF2 C5 6 FF3 3A 8 FF4 C5 0 FF5 3A E FF6 C5 2 FF7 3A C FF8 C5 B FF9 3A 5 FFA C5 9 FFB 3A 7 FFC C5 C FFD 3A 2 FFE C5 F FFF 3A 1
850 C5 4 851 3A A 852 C5 6 853 3A 8 854 C5 0 855 3A E 856 C5 2 857 3A C 858 C5 B 859 3A 5 85A C5 9 85B 3A 7 85C C5 C 85D 3A 2 85E C5 F 85F 3A 1