Whirlpool-Steuerung Manipulieren / Fernsteuern: Welches Protokoll?

[Henry (Gast)]

Liebe Experten,

ich brauche Euren Rat!
Es geht um einen Whirlpool, der in einem Ferienhaus betrieben wird. 
Dieser benötigt einige Zeit um warm zu werden. Daher wäre es toll diesen 
von Zuhause aus einschalten zu können. Eine einfache Strom an / Strom 
aus Variante geht nicht, da Umwälzpumpe, Frostschutz, Ozonator etc. 
weiter laufen müssen, auch wenn die Temperatur runter gedreht ist.

Die Temperatur wird mittels eines Bedienteils über zwei Knöpfe +/- 
eingegeben. An einem LCD Display kann man aktuelle und Solltemperatur 
ablesen.

Vom Bedienteil gehen 8 Kabel in die Steuerplatine des Whirlpools. Sie 
sind folgendermaßen bezeichnet: Key1, Key2, CS, DATA, CLK, A, DNS, +5. 
Um welche Art von Serieller-Kommunikation (Protokoll?) könnte es sich 
hierbei handeln?

Ich möchte gerne mit Arduino das Drücken des + bzw. - Knopfes simulieren 
und so die Temperatur regeln. Schön wäre es auch die derzeitige und 
Solltemperatur auszulesen. Seht ihr da eine Chance?

Vielen Dank für Euren Rat und Tipps!

Henry

[Remote O. (remote1)]

Als ersten Schnellschuss würde ich SPI tippen. Falls es das ist, kannst 
du ohne Probleme mit einem SPI2USB Konverter am Rechner mitlesen und das 
entsprechende Protokoll verifizieren.

Wenn du gar nicht über das Protokoll an deine Temperaturen kommst, dann 
kannst du immer noch den Tastendruck simulieren. Problem dabei ist nur, 
dass du die aktuell eingestellte Temperatur nicht weißt.

Als recht günstiges und vielseitiges Tool kann ich dir das AVRLab 
empfehlen.
http://wiki.ullihome.de/index.php/Hauptseite
Da ist z.B. auch ein Firmware dabei, mit welcher es möglich ist, die SPI 
Kommunikation mitzulesen.
http://wiki.ullihome.de/index.php/USBAVR-ISP-Firmwares/SPI-USB-UARTBridge/de

[Henry (Gast)]

Vielen Dank für den Tipp. Ich habe überlegt mir den Logic-Analyzer von 
Saleae zu kaufen und damit alle 8 Leitungen zu loggen, während ich die 
gewollten Aktionen durchführen. SPI sollte ich damit ja dann erkennen 
können. Bleibt nur die Frage der Belegung der Kabel, ist ja aus der 
Bezeichnung nicht alles ersichtlich.
Den Tastendruck direkt zu simulieren wird ohne Protokoll vlt. schwierig, 
da das Bedienfeld wasserdicht versiegelt ist und ich das nur ungern 
öffnen möchte... Vielleicht habe ich aber Glück und Key1 und Key2 sind 
genau die beiden Temp +/- Knöpfe.

[Remote O. (remote1)]

Wenn Key1 und Key2 schon die Knöpfe sind, besteht immer noch das 
Problem, dass du nur die aktuelle Temperatur erhöhen oder absenken 
kannst. Du weißt aber nicht wo du angefangen hast.

Sich für solch eine Aufgabe extra einen Logik Analysator zu kaufen finde 
ich übertrieben. Die Bezeichnung ist ziemlich eindeutig. Mach dich mal 
ein wenig über SPI schlau, da werden dir ganz schnell die Parallelen an 
der Belegung auffallen (CS, Data, CLK). Ich würde schon zu nahezu 95% 
darauf tippen, das es SPI ist. Da reicht dann eine einfache SPI2USB 
Bridge vollkommen aus. Das AVR Lab kann zudem auch gleich als Programmer 
für einen später angedachten µC eingesetzt werden. Für 15€ ein 
wirkliches Schnäppchen.

Hier noch ein Link zum Verständnis von SPI
http://www.rn-wissen.de/index.php/SPI

PS: ob da nun Data, SDI oder SDO steht soll dich erst mal nicht weiter 
stören
Sollte es kein SPI sein, wäre auch noch I2C möglich. Wie der Zufall so 
will, kannst du mit dem AVR Lab auch das Protokoll einfach mitloggen.

[Henry (Gast)]

Hört sich sehr gut an, vielen Dank. Ich werd mich da jetzt erst mal 
weiter einlesen. Aber du hast recht, es sieht von der Belegung sehr nach 
SPI aus...

[Ulrich P. (uprinz)]

Hi!

Auf dem Bild sieht die Beschriftung etwas anders aus:
Key1, Key2, CS, DATA, CLK, A, GND, +5.

Nach SPI riecht da garnix, eher nach I2C. Denn Für SPI müsste MOSI und 
MISO oder wenigstens Data1 und Data2 oder ähnliches zu finden sein.
Ohne gleich mit schwerem Gerät alles mit zu lesen, würde ich zuerst mal 
das Bedienteil öffnen und nachsehen, ob dort nicht der ein oder andere 
Chip mit lesbarer Beschriftung zu finden ist. Dann man suchen, was diese 
Chips so können und welche Interfaces sie unterstützen.

Es hilft auch immer mal auf beiden Seite nachzusehen, wo die Signale 
dort auf einen Chip geführt werden und welche Fähigkeiten dieser Chip an 
den entsprechenden Pinnen hat.

Da das Display ja die aktuelle Solltemperatur anzeigt, spricht nix 
dagegen, diese Anzeige über simulierte Tastendrücke zu provozieren und 
dann den Datenstrom zum Display auszulesen und diese Information dann 
auszuwerten oder ebenfalls per Internet zu versenden. Wäre eine nette 
Applikation für eine Ethernut 1.3.

Gruß, Ulrich

[remote (Gast)]

Ulrich P. schrieb:
> Nach SPI riecht da garnix, eher nach I2C.

Remote One schrieb:
> Sollte es kein SPI sein, wäre auch noch I2C möglich. Wie der Zufall so
> will, kannst du mit dem AVR Lab auch das Protokoll einfach mitloggen.

Das wurde ja auch schon angesprochen. Bei I2C stört mich persönlich 
lediglich die Chip Select (CS) Leitung. Da bei I2C eigentlich mit der 
Adresse selektiert wird.
Nichtsdestotrotz gibt es natürlich auch Bausteine welche mehrfach am Bus 
hängen können und produktionsseitig die gleich Adresse haben, so dass 
man um ein Chip Select nicht herum kommt.
Zu den Datenleitungen bei SPI, also SDI und SDA, ist es genauso gut 
mgl., dass der Baustein nur sendet und deswegen nur eine Datenleitung 
vorhanden ist. Evtl. werden die aktuelle Einstellungen ja lediglich an 
die Steuerung übergeben. Das ist ja schließlich nur die 
"Eingabeeinheit". Zudem kann es auch sein, dass nicht alle Leitungen an 
diese Stiftleiste herausgeführt sind.
Also einfach mal verfolgen, wo die Data und CLK Leitung hinführt und den 
entsprechenden Chip näher identifizieren.

[remote (Gast)]

Das Datenblatt zu dem µC, welcher oben abgebildet ist, hab ich mal eben 
angehängt.

[tom (Gast)]

Henry,

die idee mit dem logic von salae ist nicht verkehrt, da du damit 
sämtliche signale parallel und zeitlich zugeordnet loggen kannst. Ob das 
nun SPI-like oder eher I2C ist, wirst du sehr schnell erkennen können 
und dann einfach den richtigen interpreter benutzen.

das avrlab ist zwar auch eine option aber da wird es mit den 
key-leitungen und der a-leitung schon schmal.

hmmm, eine manipulation der busleitungen von aussen kann klappen, aber 
du solltest bedenken, das da auch jemand gegen deine eingespeisten pegel 
treiben könnte, also erstmal loggen, anschauen und dann einen plan 
machen - alles andere ist zuviel glaskugel.

gruss aus berlin, tom.

[Ulrich P. (uprinz)]

Muss mich korrigieren:

Die allermeisten LCD-Controller Chips, die auch SPI unterstützen, können 
nur Daten empfangen und brauchen das /CS um sich auf den SPI Datenstrom 
zu synchronisieren. CS, DATA, CLK können also sehr wohl einen 'halben' 
SPI darstellen, der nur Daten zum Display senden kann.

Es würde mich nicht wundern, wenn die Tasten einfach an einem R2R 
Netzwerk hängen und von ein oder zwei ADC Kanälen des Controllers 
ausgelesen werden.
Ich habe meine Glaskugel nicht dabei, aber es gibt eine nicht zu 
verachtende Wahrscheinlichkeit, dass die beiden Tasten Up/Down auf Key1 
und Key2 digital liegen und der Steuerkreis über eine Widerstandskaskade 
am Pin A zu finden ist. Das sollte sich sehr einfach herausfinden 
lassen, ganz ohne igendeinen Analyzer zu kaufen:

Display Einheit abstöpseln, dann
Multimeter in Ohm-Stellung an +5 und A, dann Tasten betätigen und sehen, 
ob sich dort je nach Tastendruck die Werte ändern. Das ganze mit +5V und 
Key1/2 wiederholen. Dann die ganze Reihe noch mal mit GND und A / GND 
und Key1/2.

Wenn ich damit recht habe, gibt es vielleicht immer noch einen einfachen 
und einen schweren Weg das Ding fern zu steuern:
Einfach:
Der Hersteller hat RXD/TXD als serielle Schnittstelle beibehalten und 
man kann heraus finden, wie man Parameter darüber direkt setzt.
(Bitte über Pegelwandler an den PC, nicht direkt!)
Schwer:
Man kauft sich ein Digital-Poti mit I2C oder SPI Schnittstelle und 
bringt dem Web-Server das simulieren eines Tastendruckes bei. Sorry fpr 
die Wiederholung, aber man kann auch das SPI mitlesen, dass das Display 
steuert und daraus herleiten, welche aktuellen Werte angezeigt werden.

Gruß, Ulrich

[tom (Gast)]

@ulrich:
1. denke, deine vermutung mit den analog codierten tastern ist 
wahrscheinlich zutreffend. aber da es ja paar mehr als nur key-up/down 
sind glaskugele ich eher in die richtung zwei kanäle (KEY1, KEY2) an 
adc-eingänge des uC, das lässt sich mit ohmmeter ja herausfinden.

2. der SPI oder I2C data-bus steuert wahrscheinlich das display an.

3. Leitung A könnte auch die ansteuerung für die hintergrundbeleuchtung 
oder kontrasteinstellung des displays sein. falls es ein menü zum 
einstellen gibt, könnte man das damit z.B. herausfinden oder 
ausschliessen.

4. um soll/ist temperatur oder komplette displayausgaben nach "remote" 
zu übertragen wird trotzdem nichts anderes übrigbleiben als den 
digitalen bus zu ananlysieren und die ausgaben daraus zu extrahieren. da 
sind vernünftige tools, die man auch weiterbenutzen kann nie schlecht...

5. digitales poti als taster-emulation ist eine gute idee, muss man aber 
mal schauen wegen dem widerstandsbereich der gebraucht wird. ggf. eher 
ein 8-bit port mit R2R Netzwerk spendieren.

anyway, gutt lack and häv fann, Hännrie.

[Henry (Gast)]

Moin Moin,

lange ist es her.... und nun, nach über 10 Jahren (!) habe ich mir die 
Zeit genommen mich diesem Projekt wieder zu widmen. Grund ist auch, dass 
die LCD Anzeige altersbedingt so langsam kaum noch lesbar ist.

Ich habe die Leitungen mal mit einen Logic-Analyzer (Saleae) geprüft, 
anbei ein paar Screenshots.

Das Display scheint seine Daten via SPI zu erhalten:
CS active low
DATA -> MISO
CLK -> clock
Soweit nicht überraschend.

Alle 25ms werden 138bit übertragen.
Zudem wird alle 1.28s (also alle 51 mal) zusätzlich vor dem 138bit-Paket 
ein 40bit-Paket gesendet.

Ich konnte leider noch nicht entschlüsseln, wie die Daten zu 
interpretieren sind.
Eingangs dachte ich, jedes Bit entspräche einem LCD-Segment, wie ja 
bereits angeregt wurde. Aber so einfach scheint es nicht zu sein. Ich 
habe jedes bit mal durch toggeln "blinken" lassen, um die entsprechenden 
Segmente zuzuordnen. Aber mal hat ein Bit gar keine Auswirkungen 
(jedenfalls nicht ersichtlich) und mal blinken ganze Segment-Gruppen.

Ich habe das gleiche mit dem 40bit-Paket versucht. Auch hier haben 
manche Bits keine Auswirkungen, mal blinken auf einmal ganze Bereiche 
des Displays. Ein Bit scheint hierbei alle Segmente leuchten zu lassen, 
unbeachtet der Inhalte des 138bit-Pakets.

Vielleicht ist das 40Bit Paket so eine Art Data-Latching oder 
Refresh-Anweisung?

Bsp 138bit:

110100000001000000000000001000000000010000000000000000000000000000000000000000000000000000000000010000000000000000000000001001111111010111

Hier ein Bsp. der 40bits, direkt gefolgt von den 138bit.

1100001010010000110000000000110000000010

010100000001000000000000000100000000010000000000000000000000000000000000000000000000000000000000010000000000000000000000001001111111010111

(immer dann mit "0101" am Anfang, sonst immer die "1101")

Es wäre natürlich hilfreich zu wissen welche Art von IC im Bedienteil 
verbaut ist, nur leider ist das Bedienteil verklebt bzw. vergossen.

Hat jmd. hier eine Idee wie man vorgehen könnte? Die 138Bits entspricht 
Augenscheinlich der Anzahl der Segmente, also das scheint schon der 
richtige Ansatz zu sein, denke ich.

Die Buttons, ein Buzzer und das Display Backlight werden ebenfalls via 
SPI übertragen. Dabei übernimmt eine Leitung jedoch eine andere Rolle: 
Display-CLK wird zur Data-Line und A ist nun die CLK, kein CS. Es hier 
alle 25ms (zwischen den Display Paketen) mal 6, mal 7 Bytes übertragen. 
Hier ein Bsp:

0111  1100
0111  1010
0111  0110
0110  1110
0101  1110
0011  1110
0111  1110

Das schalten des Buzzers und des Backlights scheinen Bits 7 und 6 zu 
sein. 0-5 werden genutzt um wohl die Button-Presses zu übermitteln. Also 
keine Resistor-Networks wie einst vermutet. Diesem Part werde ich mich 
widmen sobald ich das Display verstanden habe.

Also Was mir derzeit Kopfzerbrechen bereitet ist das dekodieren der 
Display Daten...
Hat jemand eine Idee?

VG, Henry

[Michael (Gast)]

Hallo Henry,
Bist du bei deinem Projekt weiter gekommen?
Mich würde auch die Ansteuerung des Panels über einen Arduino 
interessieren, da meine Hauptplatine durchgebrannt ist und ich hier 
keinen Fehler finde.
Schöne Grüße
Michael