Rocket R58 / Cinquantotto - USB Protokoll

Hallo Till, hallo Reverse Engineers,
ich habe begonnen und folgendes herausgefunden:
Es gibt zwei Touch Display Versionen. Alt: mit 1x6 Stiftleiste; Neu: USB Type B
An der Maschine ist in beiden Fällen ein USB Type A
Jedoch handelt es sich hierbei nur um die USB Hardware, die Kommunikation ist RS232.
Auf dem Mainboard der Maschine ist ein Freescale M9S8PA32A, oder NXP MC9S08PA
https://www.nxp.com/docs/en/reference-manual/MC9S08PA60RM_Rev.1.pdf
Flash: 32.768 bytes, EEPROM: 256 bytes, RAM: 4096 bytes, LQFP-44
UART0 Pin 23 und 24 wurden belegt.
Baud Rate: 115.200 bps --> Das USB Kabel kann somit nur bedingt verlängert werden (insgesamt <2m).
Default: Logic high
Beim dekodieren bin ich noch nicht weiter. Anzahl Datenbits, Parity, 1 oder 2 Stop Bits sind mir aktuell nicht klar.
Fortsetzung folgt.

 

Gibt es eigentlich mittlerweile eine Möglichkeit die Firmware zu updaten?

 

Ich hab mal unterschiedliche Blackboxes verglichen. Das sind unterschiedliche Platinendesigns und es sind sogar verschiedene Mikrocontroller verbaut. Vermutlich zum BOM reduzieren und Geld sparen.

Das war die 1.7 der R58 v2 und eine vorherige Version 1.5 oder so.

Hier die alte:

Neue:

 

Hallo Till, hallo Reverse Engineers,

trotz eines semiprofessionellen Sniffers fuer serielle Schnittstellen und zwei langer Sessions mit einem Kollegen bin ich (sind wir) an der Dekodierung gescheitert.
Das Protokoll ist extrem komplex und meiner Vermutung nach kein propietaeres Rocket Protokoll fuer die Cinquantotto, sondern auch fuer die R60 und R Nine One. Die einzelnen Nachrichten sind lang und die Kommunikation beinhaltet eine Vielzahl von Parametern. Ich tappe fast vollstaendig im Dunkeln.

Vermutlich kauft Rocket aber die Elektronik sowie die SW komplett ein. Dies schliesse ich aus den chinesischen Chip auf der Touchpanel Platine sowie den, in meinen Augen nicht fuer eine Espressomaschine benoetigten Komponenten wie Kartenslot und Lautsprecher (Speaker) Buchse.

Daher werde ich das Projekt aktuell schliessen. Falls sich jemand zu einer gemeinsamen Reverse Engineering Session melden sollte, bin ich aber wieder mit dabei. Ich benoetige einen weiteren Blickwinkel, welcher sich oft in einer gemeinsamen Runde mit gutem Espresso ergibt.

Sorry an dieser Stelle.

Liebe Gruesse

 

Ist ja ne Auftragsarbeit von Pro.El.Ind, wie oben schon erwähnt, die kommen aus der Nähe von Mailand. Bezüglich den ICs: Chinesische Chips und Fertigung sind ja omnipräsent, das sagt gar nichts.

 

Ich vermute hierzu hat niemand ein Update, oder?

Wirklich schade, dass man da nicht besser ran kommt. Den Dampfboiler nur manchmal anschalten, die Kesseltemperatur ändern… das wäre schon echt überragend, wenn man das per MQTT einstellen könnte. Ich habe vor einiger Zeit bei Pro.El.Ind nachgefragt, ob sie mir Hinweise zum Protokoll geben können—hab leider nie eine Antwort erhalten

 

Hallo Till, hallo Reverse Engineers,

das Protokoll habe ich mit meinem Kollegen zum Teil entschlüsselt. Nach unseren heutigen Erkenntnissen ist es nicht möglich, mit wenig Aufwand die Maschine an eine Hausautmatition anzuschließen.
Den Grund, warum dieses Protokoll so aufgebaut ist, kann ich nur vermuten. Entweder der Zulieferer wollte es fast unmöglich machen einen zweiten Zulieferer aufzubauen oder es handelt sich um Altlasten (Rückwärtskompatibilität).

Konzentriert wurde sich auf die Displaynachrichten, da wir ursprünglich davon ausgegangen sind, dass das Display Kommandos und Werte senden kann, aber auch Befehle von der Maschine empfangen kann. Jedoch scheint das Display keine gesetzten Werte zu übermittelt. Wie eine Synchronisation stattfindet, falls mal eine Nachricht verloren geht ist uns nicht klar.

Die Nachrichten sind 8N1 aufgebaut.

Es handelt sich hierbei um eine Art "Remote Display Protokoll". Die Maschine ist der Master und pingt dauerhaft das Display an. Datum in dezimaler Schreibweise, da Temperaturwerte so erkannt werden konnten. Ich wollte nicht immer zwischen hex und dez umschalten.

Es gibt ein RT (Display sendet) Nachrichtentype.
Byte - Dezimal - vermutete Funktion
1 - 90 - Header
2 - 165 - Header
3 - 12 - Nachritenlänge in Byte (ab hier)
4 - 131 - Nachrichtentype
5 - 16 - unklar, da immer unverändert
6 - 0 - unklar, da immer unverändert
7 - 3 - unklar, da immer unverändert
8 - 0 - unklar, da immer unverändert
9 - [x] - Displaytaste wurde gedrückt
10 - 0 - unklar, da immer unverändert
11 - [y] - Menüebene
12 - 0 - unklar, da immer unverändert
13 - 0 - unklar, da immer unverändert
14 - 216 - Checksumme Byte 1 (bei Ruhebildschirm), Berechnung nicht klar, wahrscheinlich CRC16
15 - 224 - Checksumme Byte 2 (bei Ruhebildschirm), Berechnung nicht klar, wahrscheinlich CRC16

x:
0 - Ruhebildschirm
3 - BG Temperatur +
4 - BG Temperatur -
5 - Dampfkessel Temperatur +
6 - Dampfkessel Temperatur +
7 - Grad/Fahrenheit
8 - Dampfkessel an/aus
9 - ECO an/aus
18 - Datum/Uhr +
19 - Datum/Uhr -
28 - Wochentag +
29 - Wochentag -
30 - Uhrzeit 1
31 - Uhrzeit 2
32 - Stunde an
33 - Minute an
34 - Stunde aus
35 - Minute aus
40 - Minute/Stunde -
41 - Minute/Stunde +

y:
2 - Ruhebildschirm
4 - Hauptmenü
5 - BG Temperaturmenü
7 - Dampfkessel Temperaturmenü
8 - Dampfkessel an/aus
9 - Kopiermenü
10 - Uhrzeit 1 an
12 - Datum Tag
14 - Datum Monat
15 - Datum Jahr
16 - Datum Uhrzeit
17 - Datum Minute
18 - Uhrzeit 1 aus
19 - Uhrzeit 2 an
20 - Uhrzeit 2 aus
56 - Fehler: Behälter leer

Es gibt zwei RX (Maschine sendet) Nachrichtentypen.
Kurze Nachricht:
Byte - Dezimal - vermutete Funktion
1 - 90 - Header
2 - 165 - Header
3 - 6 - Nachritenlänge in Byte (ab hier)
4 - 131 - Nachrichtentype
5 - 16 - unklar, da immer unverändert
6 - 0 - unklar, da immer unverändert
7 - 3 - unklar, da immer unverändert
8 - 104 - Checksumme Byte 1 (bei diesen Daten), Berechnung nicht klar, wahrscheinlich CRC16
9 - 100 - Checksumme Byte 2 (bei diesen Daten), Berechnung nicht klar, wahrscheinlich CRC16

Wenn das Display mit Taste gedrückt antwortet, wird eine lange Nachricht gesendet.

Lange Nachricht:
Byte - Dezimal - vermutete Funktion
1 - 90 - Header
2 - 165 - Header
3 - 35 - Nachritenlänge in Byte (ab hier)
4 - 131 - Nachrichtentype
5 - 16 - unklar, da immer unverändert
6 - 16 - unklar, da immer unverändert
7 - 0 - unklar, da immer unverändert
8 - 0 - unklar, da immer unverändert
9 - 4 - unklar, da immer unverändert
10 - 71 - unklar, da immer unverändert
11 - 4 - unklar, da immer unverändert
12 - 95 - BG Temperatur in Grad Celsius
13 - 216 - Fehlertype ?
14 - 224 - Fehlertype ?
15 - 0 - unklar, da immer unverändert
16 - 119 - Dampfkessel Temperatur in Grad Celsius
17 - 0 - unklar, da immer unverändert
18 - 0 - unklar, da immer unverändert
19 - 0 - unklar, da immer unverändert
20 - 0 - unklar, da immer unverändert
21 - 0 - unklar, da immer unverändert
22 - 1 - unklar, da immer unverändert
23 - 0 - unklar, da immer unverändert
24 - 2 - unklar, da immer unverändert
25 - 0 - unklar, da immer unverändert
26 - 104 - Verändert sich beim Heizen und bei Fehlern
27 - 0 - unklar, da immer unverändert
28 - 113 - unklar, da immer unverändert
29 - 0 - unklar, da immer unverändert
30 - 113 - unklar, da immer unverändert
31 - 0 - unklar, da immer unverändert
32 - 104 - unklar, da immer unverändert
33 - 0 - unklar, da immer unverändert
34 - 24 - unklar, da immer unverändert
35 - 3 - unklar, da immer unverändert
36 - 132 - unklar, da immer unverändert
37 - 104 - Checksumme Byte 1 (bei diesen Daten), Berechnung nicht klar, wahrscheinlich CRC16
38 - 100 - Checksumme Byte 2 (bei diesen Daten), Berechnung nicht klar, wahrscheinlich CRC16

An dieser Stelle haben wir aufgehört, da es nicht einfach sein wird, die Schnittstelle zu nutzen um Werte zu setzen. Eine Synchronisation mit den Nachrichten der Maschine ist notwendig. Einfach geht anders.

Falls jemand weitermacht, würde ich mich über eine Nachricht freuen. Vielleicht steige ich dann wieder ein.

Seid gegrüßt,
Han DeKe

 

Omg. Was für ein Kram. Das sind bestimmt Altlasten oder die Firma macht das immer so für egal welche Anwendung.. Hut ab für die Arbeit @HanDeKe

 

war das das das Display mit 25-Pol. Stecker? oder das der v3 mit USB?

Ich vermute dass es zuerst integriert designt wurde und erst später abnehmbar via Kabel (das old-school Sub-D mit 25 Pins) ausgeführt wurde (und alles beibehalten wurde). Bei v1+v2 ist das Dotmatrix LCD direkt via Bus (also GPIOs) über das Kabel an der MCU angeschlossen, die Taster ebenso via GPIOs. Vermutlich wurde bei v3 nur etwas USB drumherum gebaut. Da hilft, das Datenblatt vom LCD-Controller zu lesen, vermutlich gibts ne Lib die das schon implementiert. Aber Daten bekommt man so immer noch nicht an die Homeautomation (ohne virtuelle Screen-Emulation mit OCR).