Hallo hat schon jemand ne Ebus Kopplung zu einer Wolf Therme mit EBusd Koppler V5 hinbekommen.
Die Kopplung steht, nur die Daten sind endlose HEX Strings.
Wäre schön, wenn jemand seine Erfahrung teilt.
Ich habe auch andere Ebus Threads gelesen, nur passen diese wohl nicht zu meiner Wolf Therme.
Wäre schön, wenn jemand seine Erfahrung teilt.
Beste Grüße
Ich nutze hier zwar ein ISM7i Modul und keinen eBusd Adapter, aber ich hatte mir das vor Jahren mal kurz angeschaut. Du wirst Dich grundsätzlich hiermit
und weil Du ja eine MQTT Einbindung nutzen willst dann auch noch hiermit
und bzgl. der Einbindung unter HA und der Formatierung der MQTT Daten dann auch noch hiermit
befassen müssen, um dann die passende *.cfg Datei zu haben.
D.h. ein einfaches “Ich binde das mal per Integration X oder Addon Y ein und schon kommen die Daten passend bei HA an” ist leider mit einem eBusd Adapter nicht möglich.
Danke für die Info,
Das habe ich schon gemacht, einige Configs in /etc/ebusd ausprobiert, ohne
Erfolg. Vielleicht liegt auch am Wolf Bediengerät BM.
Die ISM7i und ISM7e laufen nur ab BM2 richtig.
Es hätte ja sein können, das jemand das Problem schon gelöst hat.
Beste Grüße
Moin,
habe auch eine Wolf mit einem BM(0), einen ebus-Adapter via ebusd in HA eingebunden und schlage mich nun mit diversen config-csvs herum, die alle nicht so richtig passen wollen. Vielleicht kann man zusammenarbeiten.
Ein paar Werte sehe ich vom BM im MQTT Explorer, in HA werden sie aber nicht angezeigt:
2025-02-22 12:22:26.434 [update notice] received update-read Broadcast RcTarget QQ=f1: 25.398;5.398;0;0;0;10.000
2025-02-22 12:22:29.155 [update notice] received unknown MM cmd: 03f1080008001900098002000f
2025-02-22 12:22:31.045 [update notice] received write hc Operation QQ=10: heat;6;25.38;-;-;10.0;-
2025-02-22 12:22:31.345 [update notice] received unknown BC cmd: f1fe050308010100ff38ff2e09
2025-02-22 12:22:32.176 [bus error] poll hc Returntemp failed: ERR: read timeout
2025-02-22 12:22:33.050 [update notice] received unknown BC cmd: 03fe05030801004000381c2e09
2025-02-22 12:22:35.969 [update notice] received write hc RcTarget QQ=10: 25.398;9.000;-;0;0;10.000
Im der Mqtt Integration habe ich folgende Ordner:
ebusd , ebusd eBUS device , ebusd/wolf , ebusd/wolf eBUS device .
Nur in ebusd sind Werte (global running , In Betrieb | global scan , "finished" | global signal , Verbunden | global uptime , 689.009 s.
Im Verz. ebusd eBUS device steht updatecheck_device, Aktuell
In den restlichen Verzeichnissen sind die Daten nicht verfügbar.
Beste Grüße
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
Nein, hatte viele vermeintlich irgendwie dazu passenden Konfigurationen ausprobiert und im Wesentlichen nur einzelne, möglicherweise passende, aber nicht wirklich zur Steuerung geeignete Daten gesehen. In einem Wust von für mich vollkommen uninterressanten Werten die meist bei Irgendeinem Default standen. Das ging auch nur mit einer korrigierten Konfig, die ich nachher auch nur einmal am Laufen hatte und nicht rekonstruieren Konnte. Also um da weiter zu kommen müsste ich sehr viel loggen und zeitkontrolliert aktiv herumstellen und mitschreiben.
Das ist mir alles zu aufwendig und lohnt für die Kiste nicht wirklich.
Ich reduziere meine Ansprüche auf einfaches Ein-Ausschalten, was ich wahrscheinlich auch durch äussere manipulation des Aussentempfühlers (ist ein NTC) via Umschaltung per SSR auf definierte Festwiderstände oder ähnlich erreichen kann. Falls die Kiste noch irgendwo einen Eingang für Raumfühler/-thermostat (ohne EBus) hat, dann eben über diesen. Via ESP oder ähnlich.
HA wird dann einfach die Kiste nach bedarf hochfahren oder in quasi-Standby versetzen.
Wichtig ist mir nur, dass da nicht der Brenner und Pumpe immer wieder anspringen, obwohl die Kiste dann eh nur gegen geschlossene Ventile pumpt.
Ja, ich habe auch aufgegeben. Habe ein ESP32 Relais mit Tasmotata geflasht und schalte damit die Therme Aus und Ein. Über einen anderen ESP habe ich mir mit DS18B20 Fühlern die Vorlauf-, Rücklautemperaturen Heizung und Warmwasser sowie die Speichertemperatur und Abgastemperatur reingeholt. Beim eBUSd ist man mit der alten Woftherme so allein. Wir sind wohl die einzigen die dieses Schätzchen noch haben und es mit eBUSd in HA einbinden wollen.
Einfach Netz-Ein/Aus möchte ich nicht, nach einer gewissen Zeit verliert die Kiste die Uhrzeit, könnte dann Probleme mit Nachtabsenkung etc. geben. Das war auch eine der Motivationen es mit eBus zu versuchen, die Chance die Uhrzeit automatisch zu stellen.
Nach meinen Recherchen im Netz hat das Jemand wohl mal hinbekommen, ist aber viele Jahre her und derjenige wohl nicht mehr aktiv, hat die Lösung auch nicht hinterlassen. Ich werde auch den Verdacht nicht ganz los, das der ein oder andere Hersteller die Veröffentlichung solcher Konfigs unterbunden hat.
Soweit ich das in Erinnerung habe gibt es auch 2 (teure) “Gateways” von Wolf mit denen das einfacher ging. Es könnte also sein, dass die Configs, die man noch online findet, zumindest zum Teil so ein “Gateway” voraussetzen. Das ist aber reine Spekulation. Kann auch sein dass sie einfach wegen SW-inkompatiblitäten mit dem aktuellen eBus-Adapter und HA nicht laufen. Oder ich das einfach nicht richtig eingebunden hab.
Ausschalten der Therme nicht Netz sondern über die Klemmen an der Leiste. Die Therme ist weiter unter Spannung. Uhrzeit hat sich nicht auf 00:00 Uhr gestellt, läuft weiter. Beim Ebus teile ich deine Vermutungen, will aber nicht glauben, dass es keinen gibt, der das geschaft hat, oder?
Was vermutlich daran liegen dürfte das der Gold-cap Kondensator, den Wolf auf seinen Platinen als Akku verwendet, das Zeitliche gesegnet hat. Bei manchen Wolf Modellen kann das schon nach 4 - 5 Jahren passieren und bei anderen hält der Gold-cap auch schon mal z.B. 7 Jahre oder ggf. noch länger aus. Mit defekten Gold-cap und somit “Pufferspeicher” für die Einstellungen und Uhrzeit, verschwindet diese nach einen ausschalten dann natürlich und z.B. irgendwelche eingestellen Zeitprogramme sind auch futsch.
Anm.: Die “Standardvorgehensweise” von Wolf, bzw. von einem Heizungsbauer, bei einem defekten Gold-cap ist dann die kompl. Platine für sehr viel Geld zu tauschen. Je nach Heizungsmodell kann ein Heizungsbauer dafür auch schon mal gut und gerne € 600 aufrufen. Ein halbwegs begabter Hobby-Handwerke, der auch mit einem Lötkolben umgehene kann, kann den Gold-cap Kondensator auch selber tauschen.
Wie lange hält der Cap denn die Uhrzeit so im Normalfall?
Da meine Kiste das einfachste Modell (CGU-2 oder so) ohne Warmwasserbereitung ist, befindet sich die monatelang im Aus-Zustand. Falls der Cap solche Zeiten eh nicht überbrücken könnte, würde es sich nicht lohnen danach zu schauen.
Platinentausch kann sinnvoll sein bei sowas, manchmal ist es nicht der Cap/Akku etc. sondern die dranhängende Schaltung zieht zuviel. Mal abgesehen davon, dass da im Normalfall auch kein Installateur dran rumlötet, wenn sich nach Cap-Tausch dann herausstellt das es nicht der Cap war, käme man um einen Tausch eh nicht herum.
Ich werde es nie verstehen, warum man bei solchen Geräten nicht gleich FRAM, Flash oder früher EEPROMs einsetzt, das nimmt sich nichts gegenüber diesen Gold-Caps oder anderen Lösungen mit volatilen Speichern und diesen immer problematischen Spannungsquellen.
Oh, das geht? Bei mir ist links vom BM ein Drehknopf, der die ganze Kiste stromlos macht.
Am BM gibts dann noch eine Standby-Stellung über den linken Drehgeber zugänglich. Ist letztere tatsächlich auch über die Klemmen auszulösen, wenn ja welche? Und was muss dran, Schalter nach Masse?
Irgendeinen Anschlussplan müsste ich hier noch haben, kann mich aber nicht erinnern etwas darin gesehen zu haben was nach einem Standby-Eingang aussah.
Das kann ich Dir leider nicht sagen, ich weiß eben nur das dieser Gold-cap bei den Wolf Heizungen eine bekannte “Schwachstelle” ist und das es eben jede Menge Betroffene gibt bei denen der Gold-cap nach x Jahren das Zeitliche gesegnet hat. Die durchschnittliche Lebenserwartung bei solchen Gold-caps wird von den Herstellern üblicherweise mit 5 Jahren angegeben. Zufällig endet auch die Wolf Garantie nach 5 Jahren.
Das der Gold-cap am Ende ist kann man eben dadurch feststellen wenn man die Heizung mal von der Stromversorgung trennt. Wenn dann das Datum, die Uhrzeit usw. weg ist/sind weiß man das der Gold-cap im Eimer ist.
Was aber weniger an der Unsicherheit liegt das es dann ggf. doch nicht der Gold-cap sein könnte, sondern eher daran das a) Wolf in solchen Fällen immer den Austausch der kompl. Platine vorsieht - schließlich wollen sie ja auch Geld durch den Verkauf von Ersatzteilen verdienen und b) Heizungsbauer üblicherweise nicht wirklich Ahnung von Elektronik und Platinen haben und noch weniger Ahnung davon haben wie man dort dann solche Kondensatoren auslötet, austauscht und wieder neu verlötet. Außerdem verdient ein Heizungsbauer natürlich ebenfalls viel mehr daran wenn er eine kompl. Platine mit seiner darauf anfallenden Marge verkaufen kann, als wenn er nur ein kleines Teilchen für 2 - 3 Euro tauscht.
Wie schon gesagt weiß ich von Leuten die für den Austausch der Platine bis zu € 600 bezahlen mussten und das weil darauf nur ein Teil für 2 - 3 € defekt ist. Aber ok, ganze Baugruppen auszutauschen, statt nur eine Kleinigkeit daran zu reparieren, ist heutzutage ja leider die übliche Vorgehensweise und das trifft ja auch auf alle möglichen Branchen zu und nicht nur auf die Heizungsbranche.
Nach dem Motto: Oh die Birne in ihrem Scheinwerfer ist defekt, tja dann müssen wir leider den kompl. Scheinwerfer tauschen, weil wir die Birne als Ersatzteil nicht anbieten und auch kein Monteur mehr weiß wie man eine Birne wechselt.
Ich habe eine Wolf CGU-2K-18 mit RM-2 Raummodul am laufen und komme so langsam über probieren an immer mehr Werte wie Temperatur am Bedienteil, Vorlauf Istwert, Vorlauf Sollwert, Warmwasser Soll, …
Hallo Andre217,das sieht ja schon super aus.Kannst du die Dateien die unter config/ebus und config/ ebus/wolf und deine mqtt-hassio.cfg mal posten. Ich bekomme mit meinen Wolfdateien keine Werte die ich auswerten kann.