unbekanntes Funkprotokoll Eberle Instat 868-r1

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

Vorheriges Thema - Nächstes Thema

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