Datenprotokoll am Display (remote control) einer LG-Wärmepumpe

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Datenprotokoll am Display (remote control) einer LG-Wärmepumpe

      Hallo,
      hat sich jemand von euch zufälligerweise schon einmal damit beschäftigt, wie die Daten von und zu "Fernbedienungen" (Displays) von Klimaanlagen und Wärmepumpen übertragen werden und wie man diese Daten für eigene Zwecke "anzapfen" könnte?
      Meine LG Wärmepumpe hat ein Display, zu dem genau drei Leitungen gehen, schwarz, gelb und rot (Minus, Daten und Versorgungsspannung). Darüber wird alles übertragen, was dem Nutzer am Display anzuzeigen ist und was der Nutzer so alles an den Tasten des Displays eingibt. Sprich ALLES. Alle interessanten Daten liegen auf dieser Datenleitung an. Und ich will sie haben, um sie zB mitloggen zu können ODER auch, um während des Betriebs gezielt Parameter ändern zu können, die ich sonst nur per manueller Eingabe am Display ändern könnte (zB eine neue Durchlflussrate für die Umwälzpumpe als Sollwert vorgeben.).
      Bei einer Eindrahtleitung, ist das dann wirklich "one wire", also so wie zB bei den Temperatursensoren DS18B20 oder ist das eine Form von I2C, bei der der Takt mit ins Signal "eingebaut" ist? Oder RS485 mit RXD und TXD jeweils nacheinander auf einer Leitung? Es geht ja auch, daß man zB eine bidirektionale serielle Übertragung mit nur einem Portpin macht ...
      Nach meiner Beobachtung ist das nicht nur bei LG so gelöst, sondern auch bei anderen Klimageräten von zB Daikin. Vielleicht gibt es da gar einen Standard? Ich kann mir nicht vorstellen, daß es auf der Leitung besonders schnell zugeht. Die Leitung ist zumindest nicht sonderlich geschirmt und man kann sie bis auf 50m (!) verlängern.

      off-topic: auf meiner Arbeit betreiben wir mehrere Daikin-Deckenkühlgeräte, jedes mit eigener Fernebedienung (Display). In einem der Räume ging die Anlage aber "schon immer" nicht aus, wenn die gewünschte (kühle) Temperatur erreicht war, sondern das Gerät kühlte munter bis zu einer Stagnationstemperatur weiter. Die Einstellungen waren alle identisch mit denen der anderen Fernebdienungen bzw. Räume und die Installationsfirma wußte auch nicht weiter ("ist wohl bei der Inbetriebnahme/Abnahme nicht aufgefallen ..."). Da es schnell gehen mußte, schaffte ich einfache Abhilfe durch einen einstellbaren mechanischen Thermostat, der bei Erreichen der (tiefen) Temperatur einfach nur die Versorgungsspannung unterbrach. Die Anlage ging sofort aus! Bei Erhöhung der Temperatur (wiedereinschalten des Kontakts) zeigt die Anlage eine kurze Fehlermeldung, fängt sich dann aber wieder und kühlt abermals bis zum Ausschalten- -> quick & dirty funktionierte und funktioniert jetzt schon seit Jahren ;)

    • @laase
      Ein I2C-Protokoll scheidet ganz bestimmt aus, weil dieses 2 Leitungen (Takt und Datenleitung) erfordert.
      RS485 ist kein Protokoll, sondern ein Übertragungsstandard und erfordert Differenz-Signale, also 2 Leitungen. Scheidet somit auch aus.
      Auch ein serielles Signal wie von einem UART (Startbit, Datenbits, Paritätbit, Stoppbit(s)) halte ich für eher unwahrscheinlich, obwohl man das auch technisch als quasi Bidirektional auslegen könnte. Dann ist es aber wieder kein normales UART-Protokoll, denn das erfordert separate Datenleitungen für Senden und Empfangen.

      Bleibt aus meiner Sicht sowas wie das 1Wire-Protokoll, ein DHT11/22 Protokoll oder denkbar auch ein Lin-Protokoll, wie es im Auto verwendet wird.

      Man müsste mal wissen, welche Spannungs-Versorgung da anliegt und ein/mehrere Oszillogramm/e sehen und das Timing der Datenbits und Amplitude zu sehen.
      Dann könnte man das mit bekannten Protokollen vergleichen, was da genauer in Frage kommt. Evtl. erkennt man da auch schon eine Struktur, ob das ein Master-Slave Pronzip ist, wo also Anfragepakete geschickte und Antwortpakete als Antwort geliefert werden, oder ob da eher nur ein Paket zyklisch zu sehen ist. Sowas könnte dann auf Lin hindeuten.
      Du kannst auch mal versuchen, die Datenleitung mit einem Widerstand zu belasten und schauen, ob die Amplitude merklich absinkt. Das würde dann auf ein Protokoll mit dominanten/zezessiven Pegeln hindeuten, wie es z.B. bei 1Wire oder LIN verwendet wird.

      Ohne die Signale anzusehen bleibt wohl nur Internet-Recherche, Herstelleranfrage oder Spekulation.

    • wow, ich bin ja total beeindruckt, dass sich schon jemand mit dem Thema so intensiv befasst hat! Danke @Schraubbaer Tobias! Das sieht jetzt zumindest lösbar aus. Ich werde wohl zwar kein Interface zu irgendwelchen HomeAssistants bauen, aber ich werde doch wohl Daten lesen und vielleicht auch die Pumpeneinstellung ändern können. Zweites ist deutlich schwieriger, da ich dazu senden muss und vorher auch die korrekte Checksum berechnen und mitsenden muss.
      Und @Mitch64: Du lagst auch richtig mit Deinem LIN, zumindest wird im zweiten Link von Tobias ein LIN Transceiver als Levelshifter verwendet.
      Ob ich nun 13 Bytes oder vielleicht sogar noch mehr habe, werde ich sehen. Ich halte es aber für seeeehr wahrscheinlich, dass auch meine Anlage diese niedrige Baudrate verwendet, von der AussieMakerGeek im ersten Link spricht. Ob ich Temperaturen mit Nachkommastellen erhalte, werde ich sehen (im Display werden nur volle °C angezeigt).
      Das alles wird auch bei mir einige Zeit dauern. Zunächst gehe ich erst einmal mit einem Shelly Uni ran und lasse mir die Temperaturen der von mir selbst extern angebrachten Sensoren schicken.