Anbindung an Heizungen mit e-Bus Schnittstelle

Begonnen von hauwech, 01 April 2014, 10:51:22

Vorheriges Thema - Nächstes Thema

deune

Hallo Zusammen,

Ich bin nun seit dieser Woche auch stolzer Besitzer eine Vaillant Gas-Terme mit einer Brauchwasserwärmepumpe, um den selbst erstellten Strom anstatt das teure Putin Gas
zu nutzen. In der Investition war auch ein ebus Koppler eservice-online drin, so dass
Ich nun Hardwaretexhnisch ausgerüstet bin.

Herzliche Grüße aus der Eifel

Holger

Prof. Dr. Peter Henning

Wir haben statt der Wärmepumpe die Dinger angeschlossen: http://p17955.typo3server.info/DF-6.11.0.html

Horizontal montiert, auf der Pergola.

Wir haben hier auch mehr Sonnenstunden als Ihr dort oben im Himalaya...

LG

pah

P.S.: Du hast natürlich vollkommen Recht: Ich habe heute 16.000 € für die Heizungsanlage überwiesen - 0,5 % davon für den Buskoppler auszugeben, ist kein Thema. Allerdings ist das Teil erst ab 15.10. lieferbar, vielleicht gewinne ich den Wettlauf.



Prof. Dr. Peter Henning

So, erste Erfolge.

1. Ich kann nur davon abraten, mit einem Buskoppler den eBus per Ethernet oder USB direkt mit dem FHEM-Server zu verbinden. Der eBus erzeugt eine erhebliche Datenlast, weil (zumindest bei Vaillant) das Steuergerät dauernd Broadcasts ausschickt. Bessere Lösung, und an dieser arbeite ich jetzt weiter: einen kleinen Raspberry direkt an die Vaillant-Heizung anschließen, und den per telnet abfragen.

2. Ich habe diesen Raspberry im Moment nicht per Buskoppler mit dem eBus verbunden, sondern direkt die serielle Schnittstelle verwendet. Bauteilkosten für das Interface bisher <5 € bei vollständiger galvanischer Trennung :-)) Schaltplan und Anleitung gibt es demnächst.

3.  Die spannende Sache ist, die Kommunikation zwischen dem Steuergerät und dem Rest der Heizungsanlage zu verstehen. Das Vaillant-Protokoll ist zwar zu großen Teilen schon gehackt worden, aber die Dokumentation ist eher auf der sparsamen Seite.

4. Bei der Datenlast und der Komplexität des Protokolls halte ich es für eher schwierig, diese Kommunikation auf einen Arduino auszulagern.

LG

pah

deune

Prima,

dann habe ich einen Buskoppler günstig zuverkaufen ;-)

Eine Himbere habe ich hier noch rumliegen, sogar im Hutschienengehäuse,
ich freue mich auf die Anleitung mit Schaltplan - selbst entwickeln könnte ich sowas nie !

Liebe Grüße aus der Eifel

Holger

Jojo11

Hallo,

mit Interesse verfolge ich sämtliche Diskussionen zu diesem Thema. Meine Vaillant Therme ist mit einem calormatic 470f Steuergerät ausgestattet. Selbiges wiederum mit einer ebus Schnittstelle. Wäre super, wenn man das in fhem integrieren könnte. Die Funkkommunikation läuft über 868 MHz, aber diese anzuzapfen übersteigt bei weitem meine Fähigkeiten :) Per Kabel wäre absolut ausreichend.

schöne Grüße
Jo


deune

Hallo Prof. Dr. Henning,

gibt es schon etwas neues z.B. Zu der Schnittstelle, dann könnte ich schon mal basteln?

Wenn es dann schon mal was zu Test gibt wäre ich dann auch schon dabei.

Liebe Grüße
Holger

Prof. Dr. Peter Henning

Ich kämpfe im Moment noch mit dem Senden auf den ebus. Empfangen läuft prima, das reicht mir aber nicht, obwohl ich schon eine ganze Menge entschlüsselt habe. Aktull werden in FHEM registriert (und geplottet)

- Brenner Vorlauf und Rücklauftemperatur, Heizungspumpenstatus
- Warmwasserspeichertemperatur, Zirkulationspumpenstatus
- Kollektortemperatur, momentaner solare Ertrag, Solarpumpenstatus

Außerdem hat der Entwicker der ebusd-Software innerhalb von einer Woche ziemlich viel an seinem Konzept geändert, das musste ich auch erst einmal nachziehen.

Bis Ende nächste Woche ersaufe ich in Arbeit. Plan ist, dann die Interface-Hardware komplett neu zu designen, mit ordentlichen Operationsverstärkern und galvanischer Trennung.

LG

pah

deune

Das sieht ja schon richtig toll aus - Respekt !

Ich freue mich auf weiteres, aber alles mit der Ruhe ;-)

Liebe Grüße
Holger

Prof. Dr. Peter Henning

Muss man natürlich kommentieren, sorry. Und

Das obere Diagramm zeigt dunkelrot die Vorlauftemperatur der Gastherme, gelesen vom ebus. Hellrot und blau sind mit 1-Wire-Sensoren gemessene VL/RL-Temperaturen.

Untere Darstellung: Schwarz ist die Speichertemperatur, gelesen vom ebus. Hellrot und blau sind mit 1-Wire-Sensoren gemessene VL/RL-Temperaturen der Warmwasserzirkulation, grau der Einsatz der WW-Zirkulationspumpe. Diese erfolgt nach Zeitprogramm der Heizung, und wird dann jeweils ausgeschaltet, wenn die Rücklauftemperatur 47 Grad erreicht. Und wieder angeschaltet, wenn sie 45 Grad unterschreitet. Wie man sieht, spart das ganz schön an der Zirkulation. Ach ja, das Gerät, mit dem ich die ZP parallel zur Heizung kontrolliere, ist das hier: http://www.fhemwiki.de/wiki/1W-WPump, sowie ein kleines Perl-Programm.

Die Ausreißer nach unten kommen jeweils von Neustarts des ebusd, da ich damit natürlich etwas experimentiere. Neben den o.a. Temperaturen lese ich von ebus noch in FHEM ein:
- Temperatur Solarkollektoren, Sollwert Speichertemperatur
- Status aller Pumpen (Heizkreis, Speicherladung, Solarkreis)

Im hier angehängten Bild ist die Temperatur des Kollektorfühlers zu sehen (hellrot). Dunkelrot ist die solare Einstrahlung in W/m^2 (hole ich aus meiner Fotovoltaikanlage). Wie man sieht, hat es heute nicht gereicht, um den Speicher über den Solarkreis zu laden. Stattdessen wurde (graue Linie !) der Speicher über die Therme geladen (dieses Datum gehört eigentlich so nicht in den Plot, es werden aber im gleichen Byte die Stati sowohl der Ladepumpe als auch der Solarpumpe angezeigt.

LG

pah

Prof. Dr. Peter Henning

OK, neuester Stand:

Ich diskutiere mit dem Entwickler von ebusd, Roland Jax, verschiedene Probleme von ebusd. Er baut diese Software gerade ziemlich radikal um, so dass derzeit keine schnelle Weiterentwicklung der Kommunikation zu erwarten ist  :(

Aktuell hat die neueste Version des ebusd 0.4.0 das Problem, dass sie nach unbestimmter Zeit die Messwerte von Bus zwar liest, den internen Puffer aber nicht mehr beschreibt. Mit anderen Worten: Ich frage in FHEM den Wert der Speichertemperatur ab, bekomme diesen auch zurückgeliefert - aber der Messwert ist seit 2 Stunden veraltet  :o

Mal sehen, wie sich das entwickelt.

LG

pah


amunra

Hallo pah,

die 0.3.0 Version scheint "stable" zu sein bzw. zumindest schon ein paar Wochen / Monate Entwicklungszeit hinter sich zu haben und damit relativ stabil.
Das einzige Problem das ich bisher festgestellt habe ist, dass der EbusD nach einer mir noch nicht nachvollziehbaren Zeit/Aktion nicht mehr über telnet ansprechbar ist.... (manchmal hilft da nur ein Strom aus/an) das kann aber auch an meiner Umgebung liegen?

Ich bin derzeit dran meine Therme (u.a die calorMATIC 420) zu entschlüsseln.... aufgrund von Zeitmangel bin ich leider noch nicht so weit wie ich ursprünglich sein wollte..

Was ich sagen möchte ist, ich würde eher auf die 0.3.0 setzen und die 0.4.0 abwarten was da kommt und dann das Modul anpassen.
Vielleicht bist du schon weiter und hast mehr Informationen sowohl in Bezug auf 0.3.0 (Bugs/Probleme) als auch in Bezug auf die Version 0.4.0?

Gruß
Arthur




Prof. Dr. Peter Henning

#26
Ja, da bin ich schon weiter. Also zu 0.3.0:

1. telnet-Problem: Lässt sich lösen, indem der watchdog des RPi den ebusd überwacht und ggf. diesen neu startet, Wenn das nicht hilft, wird der RPi neu gestartet. Auch in FHEM habe ich ein automatisches Reconnect laufen, das nach einem kompletten Neustart des entfernten RPi die ECMD-Verbindung wieder öffnet.

2. Anderer Bug (und deshalb habe ich auch mit Roland Jax diskutiert): Wenn ein get/set Befehl keinen Erfolg hat, geht der ebusd in eine Endlosschleife  :(

Edit: Roland Jax hat eine neue Version von 0.4.0 eingestellt, die ich gerade im Test habe. Verzichtet endgültig auf die relativ sinnlose Zweiteilung des Projektes in ebusd und libebus.


LG

pah

Prof. Dr. Peter Henning

Wird langsam - obwohl immer noch das Zeitproblem existiert. Kann man aber durch Watchdog etc. umgehen. Resultat: Sehr schöner Plot heute, in dem man sehr gut das Zusammenspiel zwischen gemessenem Gasverbrauch, den diversen Vorlauf- und Rücklauftemperaturen sowie den verschiedenen Pumpenzu sehen ist.

Noch etwas unübersichtlich, das mit den Pumpen.  man sieht aber z.B. in Grün (unterer Plot) den Einspareffekt meiner Pumpensteuerung (auch an den Temperaturprofilen.

LG

pah

Prof. Dr. Peter Henning

#28
Nächster Schritt: Das Zeitproblem ist gelöst.

Klare Identifikation der Ursache: Der "serielle Port" eines Raspberry Pi hat offenbar keinen dezidierten UART, sondern dieser wird an einem GPIO-Pin emuliert. Die Prozessorleistung reicht nicht aus, um die (dank fortlaufender Synchronisationsimpulse existierende) Dauerlast bei 2400 Bit/s in dieser Emulation zu verarbeiten. Als Folge davon füllt sich der Puffer - so weit, dass die Daten schließlich mit einer Verzögerung von bis zu 90 Minuten (!) weitergereicht werden. Setzt man einen UART/USB-Konverter für 4,95 € dazwischen und geht über den USB-Port in den Raspberry hinein, ist das Problem weg.

Die Kosten der EBUS-Ankopplung steigen damit auf 10 € plus Raspberry.

LG

pah

Edit: Der  "serielle Port" des Raspberry kann bei echt asynchroner Kommunikation bis zu 115 kBit/s verarbeiten, insofern ist dieses Aussteigen bei 2,4 kBit/s synchron schon etwas irritierend.  Möglicherweise könnte man auch die Zugriffsmethode in ebusd optimieren - aber, pardon, 4,95 € sind preiswerter.

kaihs

Gibt es für diese Einschränkung des UARTs irgendwelche nachlesbaren Belege?
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation