unbekanntes Funkprotokoll Eberle Instat 868-r1

Begonnen von DerD, 23 Dezember 2021, 17:20:41

Vorheriges Thema - Nächstes Thema

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
0000000000001111111000000011000110011001010110101001100110101010011001010101010110

davon ist sind 34 Bit Präambel bzw Sync:
0000000000001111111000000011000110

Der folgende Teil
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
Gruß,
Dieter

rudolfkoenig

Zitatdie 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.

ZitatMeiner 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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 :D
Gruß,
Dieter

KölnSolar

ZitatEinfach ist doch langweilig :D
stimmt. ;D
ZitatHeiß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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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 :D Und zu steuern hat sie bisher auch nichts,
Gruß,
Dieter

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

Zitat
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
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

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.
Gruß,
Dieter

Ralf9

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

ZitatUnd 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
P0=-4250;P1=2560;P2=-2570;P3=736;P4=-1080;P5=-378;P6=358;P7=-746;D=01234356567356565676565653565656765656565373565;
wird so ausgegeben
MC;LL=-746;LH=736;SL=-378;SH=358;D=88787D0;C=369;L=26;s5;b5;
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

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"?
Gruß,
Dieter

DerD

Zitat von: Ralf9 am 24 Dezember 2021, 17:52:27
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? 
Gruß,
Dieter

Ralf9

ZitatDanke, 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

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

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


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?
Gruß,
Dieter

Ralf9

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

Zitat12 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?


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



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

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


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

Gruß,
Dieter

Ralf9

Ist das der Sender?
https://www.heizungslabel.de/sites/default/files/data/Eberle/files_public/3333-9.pdf

Die Hexcodes die Du gepostet hast, sind die alle bei aktiviertem Lernmodus?
Ändert sich der Hexcode, wenn der Lernmodus beendet ist?

Laut der Anleitung hat er die folgende Betriebsarten, werden diese in der 4. und 5. Stelle übertragen. Bleibt bei Änderung der Betriebsart der Prüfcode gleich?
Komforttemperatur
Absenktemperatur 2 K
Absenktemperatur 4 K
Aus
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

DerD

Zitat von: Ralf9 am 14 Januar 2022, 18:48:18
1) Ist das der Sender?
2) Die Hexcodes die Du gepostet hast, sind die alle bei aktiviertem Lernmodus?
3) Ändert sich der Hexcode, wenn der Lernmodus beendet ist?

4) Laut der Anleitung hat er die folgende Betriebsarten, werden diese in der 4. und 5. Stelle übertragen. Bleibt bei Änderung der Betriebsart der Prüfcode gleich?
1) ja
2) ja
3) ja
4) nein / nein

Die Betriebsarten werden imho gar nicht übertragen, der Sender/Thermostat sendet im normalen Betriebsmodus immer nur An/Aus. Von der Intelligenz dahinter geht nur das Ergebnis nach draussen: An/Aus. Und da "zählt" er dann weiter, aber auch immer mit Prüfsumme.

Um mir das Problem zu vereinfachen habe ich deshalb ja auf Lernmodus geschalten. Auch konnte ich da das Senden so forcieren, dass ich in annehmbarer Zeit auf die Anzahl an Codes gekommen bin. Sonst müsste ich ja immer 10min warten. Und da, soweit meine Einschätzung, die ID immer in den Prüfcode mit eingeht, wollte ich da maximale Anzahl an Werten haben, um den Algorithmus für den Prüfcode daraus rückrechnen zu können.

Der Ansatz hat ja ansatzweise auch  funktioniert  :P
Gruß,
Dieter

Ralf9

Demnach sendet er im deaktiviertem Lernmodus nur alle 10 Min
Wie oft sendet er bei aktiviertem Lernmodus.

Kannst Du bitte mal die folgenden Hexnachrichten posten? alles mit der selben ID
bei aktiviertem Lernmodus: 2-3 Hexnachrichten
bei deaktiviertem Lernmodus:
Aus: 2 Hexnachrichten
Ein: 1-2 Hexnachrichten
Aus: 1 Hexnachricht
Ein:  1 Hexnachricht 
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

DerD

Im Lernmodus sendet er alle ~6s, immer denselben Code

Voila. Nach erfolgreichem Einlernen kommt immer noch ein Reset aus mehreren Telegrammen, beginnend mit eigentlichem Reset plus An/Aus Serie. Das habe ich der Vollständigkeit aufgenommen, vor den manuellen Wechseln An/Aus.
Fällt mir da gerade auf: diese Telegramme sind mit einem anderen Sender aufgenommen wie die anderen, der hatte die ID D14 nicht im Programm. Die beiden unterscheiden sich in der Hardware und auch Details im Sendeprotokoll (Initialisierung), aber nicht dem eigentlichen Datenteil. Möglicherweise wurden die neue Softwarerevision um weitere ID-Bereiche  erweitert. Beide werden aber vom Empfänger sauber erkannt.


Status Hex
Lernen D14 C5 D
Lernen D14 C5 D
Reset D14 45 6
Reset D14 AD 7
Reset D14 1D 6
Reset D14 A9 3
Reset D14 19 2
Reset D14 AE B
Reset D14 1E A
Reset D14 AB 1
Reset D14 A4 6
Aus D14 AC 9
Aus D14 A3 D
Ein D14 17 C
Ein D14 18 C
Aus D14 AF 5
Ein D14 1F 4
Gruß,
Dieter

Ralf9

Dies gibt einige neue Erkenntnisse.
Die Prüfziffer wird aus den ersten 5 Hexziffern gebildet.
Die 5. Ziffer sieht nach einer Art Rolling Code aus.

Aus D14 AC 9
Aus D14 A3 D
Ein D14 17 C
Ein D14 18 C
Aus D14 AF 5
Ein D14 1F 4

Sind zwischen allen diesen Nachrichten jeweils ca 10 Minuten Abstand?
Die 2. und 3. Nachricht fallen aus der Reihe. Bei den anderen bleibt bei einem Wechsel von Aus nach Ein die 5.Ziffer gleich.

Wenn Du eine Aus- und Ein Nachricht mehrmals sendest, werden diese dann auch mehrmals erkannt?
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

DerD

Zitat von: Ralf9 am 15 Januar 2022, 10:52:28
1) Die Prüfziffer wird aus den ersten 5 Hexziffern gebildet.
2) Die 5. Ziffer sieht nach einer Art Rolling Code aus.
3) Sind zwischen allen diesen Nachrichten jeweils ca 10 Minuten Abstand?
Die 2. und 3. Nachricht fallen aus der Reihe. Bei den anderen bleibt bei einem Wechsel von Aus nach Ein die 5.Ziffer gleich.

4) Wenn Du eine Aus- und Ein Nachricht mehrmals sendest, werden diese dann auch mehrmals erkannt?

1) glaube ich auch. Wenn ich im Lernmodus bei 00x den dritten/vierten Nibble nicht auf gerade/ungerade anpasse, aber den für die ID richtigen Prüfcode nehme, wird das auch nicht erkannt.
2) jein. Bei An/Aus wird diese jedesmal geändert, ist aber bald durch, da ja nur 16 Möglichenkeiten vorhanden
3) nein, wenn ich Solltemperatur ändere von min nach max sendet derThermostat gleich ein An/Aus, nur wenn es gleich bleibt muss ich notgedrungen die 10min warten
4) mehrmals senden wird mit Fehler quittiert am Empfänger

Obiges leuchtet mir völlig ein. Auch der Wert des 5. Nibbles ist quasi egal, sofern er sich nur vom vorigen unterscheidet. Sonst 4). Also der kann beim Wechsel von An nach Ausschalten gleich bleiben, muss aber nicht. Wichtig ist nur dass er sich ändert wenn der Schaltzustand konstant bleibt.

Bleibt der letzte Nibble, der zur Überprüfung notwendig ist und korrekt sein muss.
Gruß,
Dieter

Ralf9

Dies senden wird demnach nicht erkannt
Aus D14 AF 5
Ein D14 1F 4
Aus D14 AF 5
Ein D14 1F 4


Und dies senden?
Aus D14 A3 D
Ein D14 17 C
Aus D14 AF 5
Ein D14 1F 4
Aus D14 A3 D
Ein D14 17 C
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

DerD

Jeglichen An/Aus Wechsel hatte er eigentlich immer erkannt, es ändert sich ja auch was im Code. Nur wenn sich der Status nicht ändert, und der Code derselbe blieb, gab es Fehler. Das geschieht aber auf einer zweiten Ebene der Fehlererkennung, weil der eigentliche Code ja richtig ist.

Mein Testsender ist gerade nur umgebaut, so dass ich es derzeit nicht sicher verifizieren kann.

Ohne Algorithmus/Berechnung für die Prüfsumme kann ich halt keinen gültigen Code erzeugen, nur einen nehmen von dem ich weiß dass er funktioniert. Daran scheitert es derzeit.
Gruß,
Dieter

Ralf9

Beim Algorithmus/Berechnung des Prüfcodes kann ich leider nicht weiterhelfen.
@elektron-bbs ist bei sowas normalerweise recht gut. Liest Du hier mit?
oder hat jemand anders eine Idee?

Wenn sich der Code nur ändern muß, müsste es zum Schalten evtl reichen, wenn 2 Ein- und 2 Aus Nachrichten aufgezeichnet werden.

Z.B.

Aus D14 A3 D
Ein D14 17 C
Aus D14 AF 5
Ein D14 1F 4


Dann:

Ein D14 17 C
Ein D14 1F 4
Ein D14 17 C
Aus D14 AF 5
Aus D14 A3 D
Ein D14 17 C
Aus D14 A3 D



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

DerD

Ja, die simpelste aber für mich eher unbefriedigende Lösung ist eine Tabelle mit IDs (ich glaube 20 sollten in allen Fällen reichen) und den dazugehörigen Codes zum Einlernen, Reset und Schalten mit jeweiliger Prüfsumme.

In jedem Fall wäre aber komplette Generierung der bessere Weg. Und einen Teil davon habe ich ja schon, fehlt der letzte Schritt.
Gruß,
Dieter

Ralf9

ZitatJa, die simpelste aber für mich eher unbefriedigende Lösung ist eine Tabelle mit IDs (ich glaube 20 sollten in allen Fällen reichen) und den dazugehörigen Codes zum Einlernen, Reset und Schalten mit jeweiliger Prüfsumme.
Sowas liese sich auch in einem fhem Modul programmieren
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

elektron-bbs

So richtig sehe ich bei den Nachrichten noch nicht durch. Poste doch einfach erstmal, was das Teil sendet, wenn du es in Ruhe lässt, möglichst so, das nur ein Zustand gesendet wird. Also mal eine Stunde mit Zustand an und eine Stunde mit aus. Da sehen wir zumindest, ob ein rolling code im Spiel ist.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

DerD

Das habe ich schon analysiert, es gibt einen quasi-Rollingcode über 16 Werte, 0-F. Anbei der aktuelle Stand meiner Analyse zu den Sendeprotokollen, ich hoffe das ist so verständlich.

Es gibt noch bestimmte Lücken, so weiß ich nicht 100%ig sicher ob die Reihenfolge der Rollingcodes bei allen gerade/ungerade IDs immer dieselbe ist. Für An/Aus unterscheidet sie sich zumindest. Nach meinen Tests spielt das aber wohl zumindest mit dem Softwarestand meines Empfängers keine Rolle. Zusätzliche/Andere Werte kann es aber nicht geben.

Auch habe ich den Teil2 des Resets noch nicht im Detail analysiert, der Empfänger reagiert zwar mit An/Aus aber bis auf den letzten scheinen es keine regulären An/Aus Codes zu sein.


Generell:26 Bit, 2Bit Header, 24 Bit Daten

(1) Lerncode, 24Bit in 6 Nibbles
  xxx   x     x      x
  ||    ||    ||     ||
  ||    ||    ||     \/
  ||    ||    ||    Prüfcode 0-F
  ||    ||    \/
  ||    ||    Parität ID ungerade: A
  ||    ||            ID gerade: 5
  ||    \/             
  ||    Lernen ID ungerade: 3
  ||           ID gerade: C   
  \/             
ID: 000-FFF, zufällige Änderung bei jedem Lernen


(2) Reset#1, 24Bit in 6 Nibbles
  xxx   x     x      x
  ||    ||    ||     ||
  ||    ||    ||     \/
  ||    ||    ||    Prüfcode 0-F
  ||    ||    \/
  ||    ||    Parität ID ungerade: A
  ||    ||            ID gerade: 5
  ||    \/             
  ||    Reset ID ungerade: B
  ||          ID gerade: 4
  \/             
ID: 000-FFF, immer gleich


(2) Reset#2-#9, 24 Bit in 6 Nibbles
  xxx   x     x      x
  ||    ||    ||     ||
  ||    ||    ||     \/
  ||    ||    ||    Prüfcode 0-F
  ||    ||    \/
  ||    ||    An/Aus Schema, noch nicht näher analysiert
  ||    ||           
  ||    \/             
  ||    An/Aus Schema, noch nicht näher analysiert
  ||    Reihenfolge: Aus-An-Aus-An-Aus-An-Aus-Aus
  \/             
ID: 000-FFF, immer gleich


(3) Schaltbetrieb An, 24 Bit in 6 Nibbles
  xxx   x     x      x
  ||    ||    ||     ||
  ||    ||    ||     \/
  ||    ||    ||    Prüfcode 0-F
  ||    ||    \/
  ||    ||    Rollingcode ID ungerade (1 Sender): C, 3, 8, 7, F, 0, A, 5, D, 2, 9, 6, E, 1, B, 4, C
  ||    ||                ID gerade:
  ||    \/             
  ||    An ID ungerade: E
  ||       ID gerade: 1
  \/             
ID: 000-FFF, immer gleich

       
(3) Schaltbetrieb Aus, 24 Bit in 6 Nibbles
  xxx   x     x      x
  ||    ||    ||     ||
  ||    ||    ||     \/
  ||    ||    ||    Prüfcode 0-F
  ||    ||    \/
  ||    ||    Rollingcode ID ungerade (1 Sender): F, 5, A, 2, D, 6, 9, 1, E, 4, B, 3, C, 7, 8, 0, F
  ||    ||                ID gerade:
  ||    \/             
  ||    Aus ID ungerade: 5
  ||        ID gerade: A
  \/             
ID: 000-FFF, immer gleich



Gruß,
Dieter

elektron-bbs

Ohne komplette Nachrichten kann ich nichts analysieren!
Irgendwie sieht es so aus, als ob immer nur etwas invertiert wird:

  ||    ||    Parität ID ungerade: A
  ||    ||            ID gerade: 5
  ||    Lernen ID ungerade: 3
  ||           ID gerade: C

  ||    ||    Parität ID ungerade: A
  ||    ||            ID gerade: 5
  ||    Reset ID ungerade: B
  ||          ID gerade: 4

  ||    An ID ungerade: E
  ||       ID gerade: 1


Oder du hast die Datenrate nicht passend eingestellt, so das sich eine Bitverschiebung ergibt.
Lade mal einige Aufzeichnungen von URH hoch.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

DerD

Die Daten sind Manchestercodiert, die Datenrate ergibt sich da doch schon direkt aus dem Takt. Da sehe ich kein Fehlerpotential. Siehst du das anders?

Für die Nibbles 4 und 5 ist das relativ einfache "wenn-dann Logik", da fehlt eigentlich noch die Zusammenfassung und gut. Ja, das Protokolldesgn arbeitet da eben sehr stark mit bitinvertierten Codes, auch wenn ich mich die Frage warum es so gemacht wurde nicht klar ist. Aber, so fragen kann/darf man halt nicht immer. Ich verstehe zB auch nicht, warum ein Nibble mit Paritätscode plus ein extra Prüfcode existiert. Ist halt so und gut.
Nibble 6 ist für mich der aktuelle Knackpunkt weil der über Validität des Codes entscheidet.

Komplette Nachrichten habe ich doch schon hochgeladen, siehe post vom 14 Januar 2022, 13:21:55. Sogar das komplette File mit ~900 Datenpaketen. Klar kann ich dir auch die Rohdaten inklusive Replikationen geben. Nur der Mehrwert ist mir nicht klar, es sei denn du erwartest, dass deine Decodierung etwas anderes ergibt.
Einzig dass bei denen sich immer die ID ändert, aber eben nur die. Ähnliches hast kann ich auch für die An / Aus Serie machen, aber ich ar der Meinung an den IDs sieht man den Einfluß auf den Prüfcode besser. bei An/Aus ändert sich ja nur der RollingCode von 1-F, und damit der Prüfcode.
Gruß,
Dieter

elektron-bbs

Mich machte schon in deiner ersten Nachricht stutzig, das da so viele Nullen in Folge, dann Einsen und wieder Nullen die Präambel sein sollen. Bei 2-FSK ist als Präambel eigentlich ein mehrmaliger Bitwechsel üblich, wie z.B. 0xAAAAAAAA.

Dann schreibst du etwas später:

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

Das deutet auf eine sehr niedrige Datenrate hin. Diese großen Puls-/Pausezeiten kenne ich eigentlich eher bei ASK/OOK.
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

DerD

Ja, das war ein Protokoll mit neuer Softwarerevision. Ich habe zwischenzeitlich auch welche mit alter Softwarerev, aber da ist der Frequenzshift deutlich kleiner, und damit bekomme ich über URH die Signale fast nicht mehr aus dem Rauschen heraus. Das mag aber an meinen nicht ganz optimierten Parametern oder auch dem SDR liegen.

Aber ich stimme dir voll zu, diese Art an Protokoll entspricht nicht dem, was man für FM erwartet, speziell der eigentlich fehlende Synchronisationszyklus. Hat mich am Anfang auch stark verwirrt. Ist es aber mit Sicherheit. Das ist ja das schöne am SDR, dass man es mit eigenen Augen sehen kann. Übrigens auch der kleinere Frequenzshift, die beiden "Hörner" liegen da ziemlich nahe beieinander.

Die "000" oder -1080 ist aber in beiden Fällen der Übergang zum eigentlichen Datenpaket. Ich glaube, was davor kommt ist dem Empfänger relativ egal. Und für die paar Bit braucht es ja auch keine hohe Datenrate. Zwischenzeitlich hatte ich auch schon die Vermutung, das Protokoll ist, eventuell sogar bewusst, unnötig verkompliziert worden ohne aber richtige Verschlüsselung zu nutzen.

Hardwaretechnisch wird das ganze Protokoll übrigens komplett vom Controller erzeugt, also inkl. Manchestercodierung und Präambel. Der Sender ist ein TDK/TDA5100, also Steinzeittechnik gegenüber einem CC1101.
Gruß,
Dieter

DerD

Aktualisierter Zwischenstand: ich habe mir bisher vergeblich an der Methode zur Prüfsumme die Zähne ausgebissen. Es ist ein XOr und doch nicht. Irgeneine Komplikation ist noch einprogrammiert die ich nicht durchschaue. Nur falls noch jemand reinschaut und eine Idee hat. Ansonsten packe ich bei Gelegenheit die ausgelesenen Werte von 10 IDs zusammen, und man kann halt die Sensornummer nicht frei wählen sondern nur aus der gegebenen Anzahl wählen.
Ich hätte nicht gedacht, dass man 3 Hexzahlen so kompliziert verrechnen kann.

Die folgende Tabelle enthält Codes aus dem Lernmodus. Das fixiert einen Teil der Werte, und nur die ersten 3 variieren. Es geht "nur" darum die Methode zu bestimmen wie das letzte Nibble (Prüfsumme) gebildet wird. XOr passt nur bei den Werten des ersten Blocks. Wäre überglücklich zu Hinweisen bei den anderen.


000C54
002C56
004C50
006C52
008C5C
00AC5E
00CC58
00EC5A

050C5E
052C5D
054C58
056C5A
058C54
05AC56
05CC53
05EC50

0A0C5E
0A2C5D
0A4C58
0A6C5A
0A8C53
0AAC51
0ACC57
0AEC55
Gruß,
Dieter

Ralf9

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

DerD

Hallo Ralf,
Ja, habe mit Reveng einiges rumprobiert, aber auch CRC bringt nicht mehr Ergebnisse als XOr.


./reveng -w 4 -s 000C54 0013AA 002C56 0033A8 004C50
width=4  poly=0x5  init=0xc  refin=false  refout=false  xorout=0x0  check=0x8  residue=0x0  name=(none)
width=4  poly=0xb  init=0x2  refin=false  refout=false  xorout=0x0  check=0xf  residue=0x0  name=(none)



/reveng -w 4 -s 050C5E 052C5D 054C58
./reveng: warning: you have only given 3 samples
./reveng: warning: to reduce false positives, give 4 or more samples
width=4  poly=0x3  init=0xd  refin=true  refout=true  xorout=0x0  check=0x9  residue=0x0  name=(none)

./reveng -w 4 -s 050C5E 052C5D 054C58 056C5A
./reveng: no models found


Was ich so gar nicht verstehe, die Prüfsummer von 000C54 nach 002C56 ändert sich um 2, ebenso bei vielen anderen. Nicht immer 2, aber eigentlich immer gerade.
Von 050C5E nach 052C5D ändert sie sich aber nur um 1. Eigentlich kann das doch gar nicht sein.
Gruß,
Dieter

Ralf9

Hast Du auch schon mal versucht ob es bei der Prüfsumme weiterhilft, wenn Du die Hexdaten invertierst?

Hast Du wegen dem Protokoll des "Eberle Typ Instat 868-r1" und der Prüfsumme auch schon woanders gefragt?
z.B.
https://stackoverflow.com
https://www.mikrocontroller.net

evtl findet sich dort jemand der es auch schon mit dem Protokoll versucht hat
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

DerD

Invertieren? Also "0" => "F" etc? Habe ich mal gemacht, um festzustellen dass es bei XOR exakt das gleiche Ergebnis bringt. was eigntlich logisch ist.
Ein Reversen der Bits innerhalb eines Nibbles habe ich nicht gemacht. Da aber "05xxx" das gleiche Ergebnis bringt wie "0Axxx" macht ja keinen Sinn.

Ja klar, Anfragen gibt es in MC, Stockoverflow/ReverseEngineering und auch in github/RTL_433. Bisher alles ohne Erfolg. Möglicherweise meldet sich im Laufe der Jahre da mal jemand :)
Gruß,
Dieter

DerD

Ich glaube, ich habe das Rätsel geknackt. Problem war nicht der Prüfcode, sondern schon die Decodierung. Meine ursprüngliche Annahme mit Manchestercode war nur teilweise richtig, da "differentieller Manchester" verwendet wird. Daraus erklären sich dann auch die Muster, die keinen richtigen Sinn ergaben und auch die Codes vereinfachen sich.
Das ganze in URH als eigenen Decoder zusammengebastelt erhalte ich nun konsistente Ergebnisse.

Herausgefunden habe ich es tatsächlich nur deshalb, weil an Sendern mit Display die SenderID bzw. Raumnummer manuell einstellbar und inkrementierbar ist. Danach war der Rest ganz einfach.


868MHz, 2-FSK Modulation, low frequency "0", high frequency "1"
immer als 3-fache Wiederholung

Rohdaten: 82 Bit

xxxxxxxxxxxxxxxxxxxxxxxxxx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
00000000000011111110000000 11 000101010101010101010101010101010101010101010101010101
|<-- Preamble         -->| | ?? ||<- data                                        ->|

Decodierung: differential Manchester
eigentlicher Datensatz beginnt nach "000", "01" und "10" in erweiterten Präambel erzeugen zusätzlichen Overhead


DeCodiert: 30 Bit

111111010101010101010101010101
|    ||<- data             ->|
  /\
  ||
Overhead


Generell:30 Bit, 6Bit Overhead, 24 Bit Daten in 6 Nibbles LSB
"1000" => 1
"0100" => 2
"1100" => 3

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.

Gruß,
Dieter

Ralf9

Hast Du Dich schon mit der Umwandlung von normalem Manchester in Differential Manchester befasst?

Funkbus verwendet auch Differential Manchester
https://forum.fhem.de/index.php/topic,127189.msg1217330.html#msg1217330
https://github.com/merbanan/rtl_433/blob/master/src/devices/funkbus.c

Ich hab mal eine vom sduino empfangene Manchester Funkbus Nachricht von Hand in Differential Manchester umgewandelt:

0110001010110000110000001000101011101010010100111
1 durch X ersetzen
0XX000X0X0XX0000XX000000X000X0X0XXX0X0X00X0X00XXX
0 durch zo (01) ersetzen
zoXXzozozoXzoXzoXXzozozozoXXzozozozozozoXzozozoXzoXzoXXXzoXzoXzozoXzoXzozoXXX
X durch oz (10) ersetzen
zoozozzozozoozzoozzoozozzozozozoozozzozozozozozoozzozozoozzoozzoozozozzoozzoozzozoozzoozzozoozozoz
-> wandeln in Differential Manchester
zz und oo durch 0 ersetzen
z0zo0ozoz00000zo0ozozoz0zo0ozozozozoz00ozoz00000zozo00000oz0000oz0zozoz
zo und oz durch 1 ersetzen
z010110000010111010111110011000001100000100001011z


Ist recht aufwändig, geht dies auch einfacher?

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

DerD

Ich habe das in Calc gemacht, weil ich auch schpon Manchester hatte. Das war nicht schön, aber da muss man die Formel nur einmal zusammenbasteln und dann kopieren:

=TEIL(A2;1;1)&WENN(TEIL(A2;2;1)=TEIL(A2;1;1);"0";"1")&WENN(TEIL(A2;3;1)=TEIL(A2;2;1);"0";"1")&WENN(TEIL(A2;4;1)=TEIL(A2;3;1);"0";"1")&WENN(TEIL(A2;5;1)=TEIL(A2;4;1);"0";"1")&WENN(TEIL(A2;6;1)=TEIL(A2;5;1);"0";"1")&WENN(TEIL(A2;7;1)=TEIL(A2;6;1);"0";"1")&WENN(TEIL(A2;8;1)=TEIL(A2;7;1);"0";"1")&WENN(TEIL(A2;9;1)=TEIL(A2;8;1);"0";"1")&WENN(TEIL(A2;10;1)=TEIL(A2;9;1);"0";"1")&WENN(TEIL(A2;11;1)=TEIL(A2;10;1);"0";"1")&WENN(TEIL(A2;12;1)=TEIL(A2;11;1);"0";"1")&WENN(TEIL(A2;13;1)=TEIL(A2;12;1);"0";"1")&WENN(TEIL(A2;14;1)=TEIL(A2;13;1);"0";"1")&WENN(TEIL(A2;15;1)=TEIL(A2;14;1);"0";"1")&WENN(TEIL(A2;16;1)=TEIL(A2;15;1);"0";"1")&WENN(TEIL(A2;17;1)=TEIL(A2;16;1);"0";"1")&WENN(TEIL(A2;18;1)=TEIL(A2;17;1);"0";"1")&WENN(TEIL(A2;19;1)=TEIL(A2;18;1);"0";"1")&WENN(TEIL(A2;20;1)=TEIL(A2;19;1);"0";"1")&WENN(TEIL(A2;21;1)=TEIL(A2;20;1);"0";"1")&WENN(TEIL(A2;22;1)=TEIL(A2;21;1);"0";"1")&WENN(TEIL(A2;23;1)=TEIL(A2;22;1);"0";"1")&WENN(TEIL(A2;24;1)=TEIL(A2;22;1);"0";"1")&WENN(TEIL(A2;25;1)=TEIL(A2;24;1);"0";"1")&WENN(TEIL(A2;26;1)=TEIL(A2;25;1);"0";"1")

Da ich viele Daten nur in Manchester aber nicht mehr in Rohdaten hatte, ging es leider auch nur so.

Wenn mir das nochmal ankommt, würde ich mir aber wohl das Python-script hier dazu herannehmen https://github.com/triq-org/revdgst/blob/master/scripts/differential_manchester_decode.py.
Soweit ich mich entsinne, war meine Suche nach einem Code für Manchester=> diffManchester in Github und SE erfolglos. Das muss ja aber nicht heißen, dass ich nicht etwas dazu übersehen habe
Gruß,
Dieter

Ralf9

ZitatWenn mir das nochmal ankommt, würde ich mir aber wohl das Python-script hier dazu herannehmen https://github.com/triq-org/revdgst/blob/master/scripts/differential_manchester_decode.py.
Danke, das hilft weiter, damit wird es einfacher.

Hier ist es wahrscheinlich besser, wenn ich bei am Anfang fehlendem halben Bit ein Zeichen am Anfang entferne,
oder kann ich davon ausgehen, daß bei Differential Manchester die Rohdaten immer mit 0 anfangen?
Zitatdef differential_manchester_align(line):
    """Manchester align string by optionally prepending a half-bit."""
    hh_pos = line.find("11")
    ll_pos = line.find("00")

    if hh_pos < 0 or (ll_pos >= 0 and ll_pos < hh_pos):
        hh_pos = ll_pos

    if hh_pos % 2 == 0:
        return line
    else:
        return "0" + line
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

DerD

Zitat von: Ralf9 am 08 April 2022, 17:41:35
oder kann ich davon ausgehen, daß bei Differential Manchester die Rohdaten immer mit 0 anfangen?

Spannende Frage, die ich adhoc nicht beantworten kann. Wobei der Vorteil der differentiellen Übertragung genau darin liegt, dass Plus Minus sein kann oder umgekehrt und es damit eigentlich egal sein müsste. Gilt aber immer zur Dekodierung der Rohdaten, nicht wenn schon einfaches Manchester dekodiert wurde.

Ich habe mich mit Funkbus bisher nicht beschäftigt, für RTL_433 gibt es zumindest einen Decoder.
Gruß,
Dieter