Solarthermie SunGo SXL

Motivation

Angeregt durch drei Artikel unter https://hobbyelektronik.org habe ich mein Vorhaben die SunGo SXL Solarthermie Steuerung in meine Gebäudeautomation zu integrieren wieder aufgenommen. Die Artikel sind als für mich eine schöne Quelle (gewesen) meine Informationen und Daten abzugleichen und die Sicherheit zu haben, dass so wie ich mir das vorgestellt habe, scheinbar funktioniert. Was durchaus erstaunlich ist. Denn bereits zu Beginn habe ich bei der Analyse des Datensticks im Datenblatt des AT45DB081D die Taktfrequenz bis zu 66 MHz gelesen. Sollte die SunGo diese Rate ausnutzen ist eine Emulation des Datensticks doch schon recht aufwendig und alle Mikrocontroller und RasPis dieser Welt als reine Softwareemulatoren außen vor. Aber dazu weiter unten mehr.

Allgemeines

Die Gerät SunGo SXL ist eine Steuerung für solarthermische Anlagen der Firma Wagner&Co. Die Steuerung bietet die Möglichkeit des Datenloggings. Zu diesem Zweck wird an der markierten Stelle ein Stick eingesteckt. Um die Daten, die auf dem Stick aufgezeichnet werden zu visualisieren muss der Stick abgezogen werden und am PC in einen Leseadapter gesteckt werden. Dann lässt sich mit der mitgelieferten Software die Daten einlesen, anzeigen und exportieren.

Artikel

Die Artikel liefern eine Vielzahl von mitprotokollierten Daten und deren Analyse bis hin zur Beschreibung des möglichen Nachrichtenformats. Dazu herzlichen Dank, das hat mir viel Zeit gespart. Auch die Interface-Implementierung mit Hilfe eines ATmega328 und der Datenaufbereitung durch einen RasPi ist eine gelungene Referenz. Zwischendrin haben mich dann aber immer mal wieder Aussagen unsicher gemacht, die ich nicht nachvollziehen konnte. Dazu gehörten z. B. die Aussagen "Datenstick als Sackgasse herausgestellt" und "Leider stellte sich heraus, dass der Regler für den "zweiten Kanal" keinen Chip select herausführt." Der Interface-ATmega hat MISO nicht angeschlossen. Was ist mit den Daten die die SunGo lesen will!!! Da ich diese Dinge nicht nachvollziehen kann habe ich mich entschlossen "meinen" Weg zu gehen und mir mit den Erkenntnissen der Artikel nur Gewissheit zu verschaffen, dass ich nicht in Fallen tappe, die bereits ausfindig gemacht wurden.

Vorbemerkungen

Im ersten Analyseschritt konzentriere ich mich ganz auf die Daten auf dem Datenstick. Wenn es gelingt das Datenformat zu "lesen" kann man daraus schließen welche Daten am Port der Steuerung übertragen werden und zwar in beide Richtungen! Es ist doch sehr erstaunlich, dass durch einen fehlenden Stick und damit fehlender Parameter z.B. des Log-Intervall die Steuerung doch freiwillig Daten an den Stick sendet. Die Analyse der Kommunikation der SunGo über den MiniDIN-Port kommt erst später, sobald die Daten des Datensticks interpretierbar sind.

Analyse

Den Datenumfang sieht man am schönsten in der Datalog-Software (Datalogging Solareg II)

Datalogging-Software (V2.02.16) Menüstruktur:

• Datei
  • Lese Datastick (STRG-L)
  • Öffnen (STRG-O)
  • Initialisiere Datastick
  • Log-Intervall setzen
  • Speichern
  • Drucken..
  • Beenden
• Optionen
  • Sprache
  • Auslesegeschwindigkeit anpassen
  • Rohdaten Datastick lesen
  • Datastick löschen
  • Bezeichnungsänderungen löschen
  • Schreiben des Datasticks ermöglichen
  • Ertrag dokumentieren
• Hilfe
  • Inhalt...
  • Über..

Als Analysezeitraum diente eine Aufzeichnung vom 03.11. (Start 04:16 Uhr) bis 14.11. (Ende 12:56 Uhr). Zur Aufzeichnnug stehen folgende Werte zu Verfügung:

• Uhrzeit
• T1 Koolektor °C
• T2 Speicher unten
• T3 Speicher oben
• T4 Thermostat A
• T5 Poolschutz
• T6 Ertrag T
• T7 Rücklaufanhebung T
• T8 Rücklaufanhebung T
• T9 T
• Strahlung W/m²
• Speicher kWh
• Speicher h
• Funktion aktiv 1
• Funktion aktiv 2
• Volumenstrom l/min

Wobei hier noch nicht deutlich erkennbar, ob gerade die letzten ab Strahlung, Werte sind die in der Datalog-Software aufbereitet sind und sich somit gar nicht als Rohdaten auf dem Datenstick befinden.

Anzahl Datensätze: (Aufzeichnungsintervall 1 Minute)

• 03.11. 1184
• 04.11. 1440
• 05.11. 1440
• 06.11. 1440
• 07.11. 1440
• 08.11. 1440
• 09.11. 1440
• 10.11. 1440
• 11.11. 1440
• 12.11. 1440
• 13.11. 1440
• 14.11. 777 in Summe 16361 Einträge

Der benutzte Datenstick hat eine Größe von 8 Mbit. Die Funktion "Rohdaten Datastick lesen" erzeugt eine Datei namens "debug.bin" mit einer Größe von 2 MiB. Da kommen doch Zweifel auf, dass es sich wirklich um die Rohdaten auf dem Stick handelt.

FlashCat liefert den tatsächlichen Inhalt des EEPROMS. Und siehe da. Das was da in debug.bin drin steht ist nach meinem Verständnis gar kein "binärer" Inhalt, sondern eine TXT-Datei, die die hexadezimale Entsprechung der eigentlichen Binärdatei in ASCII enthält. Beispiel: In der Binärdatei steht HEX AA 55 01 05 ... Dies ist die hexadezimale Darstellung der Binärdaten 10101010 01010101 00000001 00001001 ... im EEPROM. Wenn man nun diese AA 55 01 05 in ASCII codiert erhält man 61 61 35 35 30 31 30 35 .... Dadurch erklärt sich die doppelte Dateigröße. Die Verwendung eines solchen Formates (Codierung) erschließt sich mir nicht.

Als Grundlage für die weitere Untersuchung dient natürlich jetzt die "korrekte" Bin-Datei. Die Binärdatei hat folgende Struktur:

0x00000 0 AA 55 XX XX XX XX File Signatur erinnert an die Magic Number 0x00006 6 FF ... FF 01 0x00010 16 20 57 61 67 ... Wagner& Co ... 0x00100 8 Byte Datum 0x00210 Kopfdaten

0x00520 In Blöcken von jeweils 264 Byte Daten (Datum (8 Byte) + 4 * Werte (64 Byte))