Hallo zusammen,
vor knapp zwei Jahren gab es hier -> http://forum.fhem.de/index.php/topic,7768.0.html (http://forum.fhem.de/index.php/topic,7768.0.html) schon mal eine Anfrage, ob die Kopplung fhem <-> eBus möglich ist.
Gibt es zu dem Thema neue Erkenntnisse?
Bei eService (http://www.eservice-online.de/eBus/ (http://www.eservice-online.de/eBus/)) gibt es einen USB- und einen LAN-Adapter für eBus. Es wäre für User, die eine Heizung mit dieser Schnittstelle betreiben, sicher seeeehr interessant, ob man dort nicht mitlauschen kann, was die Heizung so treibt.
Gruß Roland
Hallo hauwech,
der LAN-Adapter für eBus wäre interessant! (da ich keine freie USB an meinem FB mehr habe)
Das Problem ist, wie bindet man es in Linux ein? Wenn man Daten austauschen könnte, wäre es kein Problem mehr ein Modul dafür zu stricken.
Gruß, Gerhard
Hallo Gerhard,
ich habe auf der Herstellerseite gerade nochmal nachgelesen. Dort heißt es:
Zitat...Es sind Treiber für Windows Betriebssysteme verfügbar. ...
Wahrscheinlich ist DAS schon das K.O. Kriterium. Schade. Bliebe der USB Adapter...
Gruß Roland
Hi,
es gibt den ebusd (daemon) für linux siehe da: http://www.cometvisu.de/wiki/index.php?title=Ebusd (http://www.cometvisu.de/wiki/index.php?title=Ebusd)
Den eBus Koppler Ethernet kann mann ganz einfach über IP anschliessen und dann, wiessen wie?, mit ihm kommunizieren.
Leider ist der momentan nicht lieferbar.
Gerhard
Hallo Gerhard,
das klingt spannend.
Leider stecke ich weder in solchen systemnahen Themen noch in fhem (hab' ich erst seit ca. vier Wochen...) tief genug drin, um was Hilfreiches beisteuern zu können.
Gruß Roland
ok,
warten bis ich den Koppler bestellen kann, dann werde ich ihn über ECMD versuchen ins FHEM einzubinden.
Gerhard
Hallo Gerhard,
der eBus Koppler scheint lieferbar zu sein - zumindest 1 Stück :-)
http://www.eservice-online.de/eBus/eBUS-Koppler-Ethernet.html (http://www.eservice-online.de/eBus/eBUS-Koppler-Ethernet.html)
Gruß Roland
Hi,
habe auch sofort (letzte Woche) bestellt!!
Kommt vll. Anfang der Woche??
Gerhard
Cool!
Ich bin gespannt, was da so geht.
Gruß Roland
auch mich interessiert das thema sehr. ich habe schon einige factory daten meines brenners mit eBus zusammengesammelt, die anbindung aber im moment auf die lange bank geschoben.
so eine fixe idee, flugs eine alte lambdasonde in das rauchrohr, thermometer dazu, etwas brennerspezifischen code tackern, und fertig ist die lambda-nachrüstung (sparsam und umweltfreundlich :) natürlich)
LG, florian
Hallo,
bin gerade auf diesen Thread gestoßen, gibt es denn hier schon einen aktuellen Zwischenstand ?
Vielen Dank und einen schönen Tag
Kalle
Ich habe gerade eine neue Vaillant-Heizung mit allem Drum und Dran installieren lassen. Bin auf jeden Fall mit dabei, die Ankopplung des eBus an FHEM zu realisieren.
Allerdings bin ich an dem Buskoppler nicht wirklich installiert - es reicht vollkommen aus, ein kleines Stück Hardware zur Umsetzung des eBus auf RS232 zu realisieren, das ich dann mit einem USB/Serial-Adapter an meinen Cubie anschließe. Ich habe damit sehr gute Erfahrungen gemacht, ein USB-Node meines Cubie liegt sowieso im Keller wegen der Fotovoltaikanlage.
LG
pah
OK, ein paar Fortschritte...
Die Anbindung des eBus an FHEM ist deshalb kritisch, weil der eBus so langsam ist (2400 baud). Sowohl die Anbindung des Ethernet/eBus Konverters über ECMD, als auch eine direkte USB-Anbindung des eBus an FHEM macht deshalb nicht viel Sinn. Wir haben bei meinen 1-Wire Modulen festgestellt, wie sehr so etwas FHEM ausbremsen kann.
Der richtige Weg ist also die FHEM-Anbindung über ein externes Programm, in diesem Fallen den ebusd http://www.cometvisu.de/wiki/index.php?title=Ebusd
Einen Buskoppler kann man für weniger als 10 € zusammenlöten. Auf http://ebus.webhop.org/twiki/bin/view.pl/EBus/EBusKonverter gibt es eine ganze Latte von Schaltplänen, ich werde mal versuchen, einen möglichst einfachen Koppler auf Basis dieser Pläne zu bauen. Den dann mit Ethernet, statt USB zu versehen, ist trivial - das habe ich bei 1-Wire auch gemacht.
LG
pah
wirf doch mal einen Blick in OWX_ASYNC (insbesondere OWX_DS9097) um zu sehen, wie man niedrige Baudraten bedient, ohne das Fhem anschließend lahmt.
Bei den Bauplänen gefällt mir die Variante mit dem Arduino, wenn man dem Sketch noch etwas aufbohrt und ein Enc28j60 Ethernetmodul dranhängt könnte man einen Netzwerkgekoppelten Buskoppler für weniger als 20 Eur realisieren.
Gruß,
Norbert
(der leider keine Heizung mit eBus hat um selber tiefer einzusteigen...)
Lieber Norbert,
ich hätte ja voraussagen können, dass Du einen Arduino bevorzugst ;)
Oder dass Du mich auf OWX_ASYNC verweist...
[OFF-TOPIC Ich bin mit der asynchronen Erweiterung von OWX immer noch etwas über Kreuz. Vor allem deshalb, weil Du in OWX verschiedene Anpassungen vorgenommen hast, die zwar für den asynchronen Teil ganz nützlich sind - aber OWX doch sehr stören. Beispiel: Verzicht auf eine vollständige Bussuche, wenn "get ... devices" ausgeführt wird. Mir fehlt aber im Moment die Zeit, das auf futures and promises umzubauen].
In dem Fall aber hast Du tatsächlich sogar Recht. Man könnte mit einem Arduino eine Abstraktionsschicht realisieren, die das eBus-Protokoll verschiedener Hersteller in einen gemeinsamen Befehlssatz für Heizungssysteme umwandeln. Mal drüber nachdenken.
LG
pah
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
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.
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
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
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
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
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
Das sieht ja schon richtig toll aus - Respekt !
Ich freue mich auf weiteres, aber alles mit der Ruhe ;-)
Liebe Grüße
Holger
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
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
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
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
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
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.
Gibt es für diese Einschränkung des UARTs irgendwelche nachlesbaren Belege?
Wie soll ich diese Frage denn verstehen ? Was man im Internet nachlesen kann, ist Wahrheit ? ::)
Mein Tipp: Selber ausprobieren.
pah
Ich dachte eher an ein Datenblatt, da findet man so was im allgemeinen. Und ich kann es da nicht finden.
Datenblätter gibt es wie Sand am Meer, z.B. hier http://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf,
oder Anleitungen wie diese hier von meinem Kollegen Jürgen Plate: http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Serial.html
Das sagt aber noch nichts darüber aus, wie auf der untersten Ebene die Register bedient werden, und auch auf der Plate-Seite findet man nichts zur Performance des RPi bei synchroner Dauerlast.
LG
pah
Hallo pah,
gibt es schon etwas neues? Da nun die Max! Thermostate wieder ordentlich laufen, kann ich mich
um die Schnittstelle zwischen diesen und der neuen Gastherme und Brauchwasserwärmepumpe kümmern.
Liebe Grüße aus der Eifel
Holger
Ja, selbst gebautes Interface läuft bestens. Allerdings habe ich im Moment extrem wenig freie Zeit, weil Ende dieser Woche der 2. Jahresreport eines von mir koordinierten EU-Projektes fällig ist. Sonst hätte ich den Schaltplan und weitere Details längst hier veröffentlicht. Also bitte noch etwas Geduld.
LG
pah
SO: läuft. Neuer Thread http://forum.fhem.de/index.php/topic,29737.0.html