Oh man, ich habe auch noch so ein Teil rumliegen, eins meiner offenen Projekte. Ich habe eine Wolf CGS24 mit einem BM (0) . Wäre cool wenn man hier erste die Dateien zum probieren hätte…
Ich habe meine aktuellen Bestrebungen mal hochgeladen:
Aber bitte mit Vorsicht genießen, ich bin noch sehr viel am ausprobieren, es waren auch schon mehr Werte verfügbar als gerade 
Lasst mich wissen, wenn ihr neue Erkenntnisse habt, ich pflege die gerne ein und teste gegen.
Kann ich das ebusd eigentlich parallel zum Bedienmodul anschliessen?
Ja klar, das ist ja ein Bus-System
Hallo Andre, Deine config sieht sehr vielversprechend aus … ich hab immer mal wieder geschaut, wie sich das eBus-Shield entwickelt und bin jedesmal wieder davor zurueckgeschreckt weil zu Wolf Geraeten nur sehr wenig Informationen zu finden waren.
Ich hab stattdessen ganz simpel einen ESP mit 8 230V auf TTL Wandlern (mit Optokopplern) an die Ausgaenge der Heizungsregelung gehaengt und und 1-wire DS18B20 an die Rohre. Das taugt fuer das Monitoring mit Home Assistant ganz gut, aber die Daten direkt vom eBus zu bekommen waere eine enorme Verbesserung.
Aus Deinen Beitraegen lese ich, dass Deine Therme ein BM und ein RM-2 hat.
Ich hab einen Kessel mit Regelung R3, Bedienmodul BM und Mischermodul MM. Ich denke, meine Anlage ist Deiner recht aehnlich und ich finde sowohl R3 als auch das MM in der wolf.json.
Ich werd jetzt einfach mal ein eBus-Shield bestellen und testen.
Eine Frage noch: hast Du (oder ein Mitleser) vielleicht zusaetzlich noch 1-wire Sensoren an dem eBus-shield? Ich werde aus der aktuellen Doku nicht schlau. 2023 gab es mal ein Issue dazu und die Funktion wurde in die Firmware eingebaut - jetzt ist dazu aber nichts mehr zu finden.
Ich hatte mich dann mal mit den Unterlagen zur Therme beschäftigt, ein paar Versuche gemacht und eine externe Steuerung zu meinem Selbstbau-eBus-Adapter dazu gebastelt.
Ziel: Minimalinvasiv, aber mit trotzdem maximalen Möglichkeiten einer Steuerung/Regelung mittels HA unter Einbeziehung der einzelnen Raumtemperaturen und Thermostatventilen (die dann wohl eher zu reinen Aktoren degradiert werden).
Aktueller Stand:
-Die Netzversorgung der Heizung ist durch einen WLAN-Schalter mit Leistungsmessung schaltbar, so kann man auch im Sommer alle paar Tage einschalten (gesteuert durch HA) um die Uhrzeit zu erhalten und evtl. die Pumpe mal kurz laufen zu lassen.
Über die Leistungsmessung erkennt man mit Schwellwertschalter in HA dass die Pumpe läuft, vermutlich könnte man auch so den Brenner detektieren. Hab ich aber über A1 an den detached Schalteingang des WLAN-Schalters realisiert.
-ein ESP32 C3, versorgt durch den eBus (den Aufbau hatte ich ja noch vom selbstgebastelten eBus-Adapter) misst Vorlauf und Rücklauf per TC74 (I2C-Sensor). Vorsicht, ein ESP8266 geht nicht, der braucht beim Booten so viel Strom das der eBus beeinträchtigt wird. Wegen Versorgung aus dem eBus ist galv. Trennung zum Rest nötig. Der ESP Schaltet zwischen Aussentemperaturfühler (einfacher 5k-NTC) und einem NTC-Simulator um, per SSRs. Praktischerweise ist im Manual der Heizung eine Tabelle R(NTC)->Temperatur. Zudem gibt es ein SSR für den Standby-Eingang E1.
Von WLAN-Problemen und dem (gelösten) Problem einen Pin der PWM machen soll, auf 40mA drive level zu stellen, mal abgesehen, funktioniert das ganz gut. Aufgrund der Nichtlinearität von NTC, sonstigen Bauelementen (Koppler) und sonstigen Einflüssen (Pintreiber, etc.), hab ich da gar nicht gross rumgerechnet, sondern gleich eine Tabelle PWM->Aussentemp.Anzeige aufgenommen, mit dem Ziel einfach in Excel mittels Regression eine Übertragungsfunktion zu bekommen.
Das Ergebnis war umwerfend: Mit R²=0,996 bekommt man eine Geradengleichung 
mit R² 0,9995 ein Polynom mit minimalem quadratischen Anteil. Als Kommastellenfetischist hab ich natürlich das Polynom genommen.
Des Rätsels Lösung liegt wohl einfach in der Diode im Koppler, die wirkt quasi umgekehrt zum NTC und so verbleibt nur noch minimale Nichtlinarität.
Falls jemand sowas nachbauen will, kann ich den Schaltplan zur Verfügung stellen. Allerdings sind meine Teile aus dem Fundus, also nicht unbedingt nach dem günstigsten erhältlichen ausgesucht und über den konkreten Aufbau auf überfülltem Lochraster rück ich nichts raus Die Software, in ESPHome gestrickt ist auch eher so dahindilettiert…
Da auf meinem Aufbau aber noch der eBus-HW-Teil erhalten geblieben ist, freue ich mich natürlich über den Ansatz von andre217.
Vielleicht bekomme ich es ja hin, in ESP-Home eine Adaptersoftware zu stricken die gemeinsam mit dem bisherigen läuft. Lesend soll das schon mal funktionieren. Mit Timingproblemen ist aber zu rechnen, womöglich muss man gezielt Ruhephasen am Bus ausnutzen, was natürlich nur mit einer sehr einfachen Gerätekonstellation geht.
Moin
Schöner Ausdruck, 
aber das wäre m.M.n. dann doch eher einfach ein ISM7-Modul zu benutzen (sofern das bei der jeweiligen Wolf Anlage möglich ist), über das einem dann eben auch ohne große Bastelei und Aufwand direkt alle Features unter HA zur Verfügung stehen. Bsp.:
Ja dafür müsste man dann je nach Modul (i oder e) und je nach Marktlage und Anbieter, zwischen € 150 und € 250 investieren, aber das wäre dann eben eine minimalinvasive Lösung. Die Möglichkeit per eBus und irgendeinem Adapter wäre dann eher eine möglichst kostengünstige Lösung, bei der man eben auch Abstriche machen muss.
Nicht falsch verstehen, ich finde es toll das Du Dir über eine Variante per eBus + Adapter weiter Gedanken gemacht hast und diese hier auch postest und teilst. 
VG Jim
Der Weg des Selbermachens ist das Ziel
Ich werde aus manchen Infos auf diesen Seiten auch nicht schlau. Da gehen Links in Leere, vieles ist wohl depubliziert. In den letzten Tagen hatte ich auch in diesem Umfeld gelesen, dass zusätzliche Aufgaben das Timing durcheinanderbringen und man das daher in einen Zweit-ESP auslagern solle. Bezog sich aber möglicherweise auf ältere HW-Versionen (es hat ja auch einiges mit ESP8266 gegeben).
Mein Eindruck: Ja, schwierig, auch bei ESP32. Das hängt halt vom zusätzlichen Software-Overhead für die Sensoren und den Latenzen für die Übertragung der eBus-Inhalte ab.
Individuell würde das sicher trotzdem gehen, wenn man halt (durch Beobachtung) bekannte längere Phasen für Sensoraktivität und -datenübertragung ausnutzt, wenn gerade auf dem eBus nix los ist. Das kreigt man aber wohl nur schwer für alle Szenarien mit eBUs-Vollaustattung aller Gerätehersteller hin.
Die Art der Sensoren spielt auch eine Rolle. 1-Wire ist wahrscheinlich komplett in Software implementiert. Hab mein ganzes Berufsleben die Finger davon gelassen und werde das auch weiterhin tun. Für I2C, SPI, UART dagegen haben moderne Prozessoren meist gute HW-Unterstützung, die Resourcen sparen und Laufzeiteffekte klein halten.
Aber auch bei schön interruptgesteuerter Proz.Peripherie sollen ja die Ergebnisse kommuniziert werden, und da könnte es dann trotzdem wieder am Flaschenhals des Kanals zu ebusd scheitern, der in den meisten Fällen eh WLAN sein wird. Eigentlich ist der ganze Ansatz “ebusd-Verarbeitung auf leistungsfähigem (aber nicht wirklich Echtzeit) Rechner verlässt sich auf (mehr oder weniger) dummen Adapter der über mindestens latenzwackeligem Kanal angebunden ist” ziemlich problematisch, auch wenn die 150ms zwischen den Synchs schon fast eine Ewigkeit darstellen. Mich würde ja interessieren ob wenigstens die “Spezialitäten” des eBus, wie z.B. wegen Busarbitrierung verbotene Nutzdateninhalte und die Folgen, zumindest teilweise auf dem Adapter erledigt werden.
Aber es ist da wohl reagiert worden, es gibt Micro-ebusd:
https://token.ebusd.eu/
Wenn ich das richtig interpretiere kann man jetzt durchaus eine technisch sinnvollere Lösung bekommen. Potentiell mit Möglichkeiten individueller Zusatzfunktionen (Sensoren), jedenfalls würde wohl der Flaschenhals Übertragungslatenzen wegfallen und man könnte Sensoren lokal gezielt in Buspausen triggern. Aber keine Ahnung in wie weit man da Einfluss drauf hat, vermute den Source bekommt man nicht, wenn dann eher eine konfigurierbare Auswahl an festgelegten Sensoren.
Wäre mir zu wenig, ich würde mindestens meinen genialen PWM-NTC Emulator einbauen wollen 
Oder irgendwelche anderen Sensoren/Aktoren die ich in dem Raum noch gerne hätte, muss ja gar nichts mit Heizung zu tun haben.
Ich hab mir jetzt ein eBus-Shield C6 geholt und mal provisorisch angeschlossen. Das hat ganz einfach geklappt: eBus-Stecker ist dabei und mit der default-config hat er auch gleich etwas erkannt. Danach hab ich versucht, den ebusd auf einer LXC zu kompilieren, aber unter Arch Linux klappt das mit dem MQTT nicht - also Debian und die Pakete aus dem Github repo installliert.
Der ebusd hat das shield auch gleich gefunden und fleissig messages eingesammelt - aber die haben nur leidlich zu den Beispielconfigs gepasst. Auch was ich so im Netz gefunden habe, passt groesstenteils nicht. Ich bin dann auf die ominoese “wolf.json” gestossen, die aus den ISM Adaptern extrahiert ist und die messages aller moeglichen Wolf-Geraete enthaelt. Mit try&error hab ich damit ein paar Werte auslesen koennen, aber entweder ist die Doku falsch, oder die Firmware meiner Heizungkomponenten ist zu alt (das System wurde 2006 installiert und seither nicht mehr veraendert).
Ich bin dann dazu uebergegangen, mir die Broadcasts anzuschauen, die auf dem eBus im 10/20/30/60sek Takt auftauchen und hab mit Hilfe von Beitraegen aus den FHEM und Homematic Forum und den eBus issues/discussion auf Github fast alle Werte identifizieren koennen, die mich interessieren.
Die meisten kann man direkt als Sensoren im Home Assistant nutzen (wenn man mal verstanden hat, dass das eBus-MQTT Gateway defaultmaessig alle messages filtered deren Name nicht “status”, “temp”, etc enthaelt).
Durch die Broadcasts muss ich fast nichts aktiv auslesen und schreiben will ich sowieso (erstmal) nicht: die Heizung hab ich die ersten 2 Jahre so eingestellt, dass ich nichts nachregeln muss. Der Heizungsbauer hat wohl gute Arbeit bei der Planung geleistet und ich konnte die FBH so anpassen, dass sie komplett ohne Stellantriebe auskommt. Das hab ich zuerst mit Thermometern gemacht, dann mit DS18B20 an jedem Heizkreis. Der Kesselkreis versorgt nur die Heizkoerper im Bad und ansonsten macht alles der Mischer.
Der ist jetzt allerdings auch die letzte Baustelle: ich hab zwar die Werte wie Soll-Temperatur und ob die Pumpe laeuft oder nicht, aber ich haette gerne die Mischer auf/zu messages … die hab ich noch nicht herausgefunden.
Mit dem eBus Shield hab ich jetzt aber schon deutlich mehr Informationen als bisher mit den DS18B20 und nur den 230V-TTL Wandlern.
Vielleicht kann mir mit den Mischer-Kommandos jemand weiterhelfen … laut “wolf.json” sind das die Kommandos cc5200 - aber die gibt es 3x.
Ich hab keine Ahnung, wie ich die Werte aus der “wolf.json” fuer das Mischermodul MM als message fuer den ebusd codieren soll.
| name/DEU | RemoveConditionId | ReadOnlyConditionId | InactiveConditionId | IsSnapshotTransmitEnabled | Decimals | ControlType | converter/type | converter/TelegramNr | converter/BusconfigProcessingType | converter/Type | read_command | KeyValueList/0/key | KeyValueList/0/value/DEU | KeyValueList/0/value/ESP | KeyValueList/0/value/GBR | KeyValueList/1/key | KeyValueList/1/value/DEU | KeyValueList/1/value/ESP | KeyValueList/1/value/GBR | KeyValueList/2/key | KeyValueList/2/value/DEU | KeyValueList/2/value/ESP | KeyValueList/2/value/GBR | converter/TelegramNrOpen | converter/TelegramNrClose | MinValueCondition | MaxValueCondition | StepWidth |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ausgang MKP | C_2049 | True | False | false | ComboBoxText | NumericConverter16Template | 82 | US | CC5200 | 0 | Aus | OFF | OFF | 1 | Ein | ON | ON | |||||||||||
| Mischerkreispumpe | C_2049 | True | False | false | ComboBoxText | NumericConverter16Template | 82 | US | CC5200 | 0 | Aus | OFF | OFF | 1 | Ein | ON | ON | |||||||||||
| Mischermotor | C_2061 | True | False | false | ComboBoxText | MixerStateConverterTemplate | Mischer | CC5200 | 0 | Aus | OFF | OFF | 1 | Zu | Cerrado | Closed | 2 | Auf | Abierto | Open | 86 | 87 |
Fuer das MM2 sind die auf/zu Werte nicht so komisch - da gibt es eigene Steuerkommandos, die eBus Konfigurationszeilen ergeben bei mir aber keine sinnvollen Werte:
r9,mm,status_mkp,Mischerkreispumpe,51,5022,CC5200,mischerkreispumpe,UIN,0x00=Aus;0x01=Ein,Mischerkreispumpe
r,mm,mischermotor_offen,Mischermotor offen,51,5022,CC5600,mischermotor_offen,UIN,0x00=Aus;0x01=Zu;0x02=Auf,Mischermotor offen
r,mm,mischermotor_geschlossen,Mischermotor geschlossen,51,5022,CC5700,mischermotor_geschlossen,UIN,0x00=Aus;0x01=Zu;0x02=Auf,Mischermotor geschlossen
cc5200 ist immer “Ein”
cc5600 und cc5700 sind immer 32768
Ach ja - meine Frage von oben kann ich jetzt selber beantworten: ja, an das eBus-Shield kann man alle moeglichen Sensoren anschliessen. Die GPIOs sind aehnlich nutzbar wir unter Tasmota oder Esphome.
Moin
Jepp und die nutze ich hier auch per ism7mqtt, aber Deine Frage(n) dazu weiter unter verstehe ich leider irgendwie nicht.
So eine *.json sieht dann z.B. ja so in der Art aus
{
"Devices": [
{
"ReadBusAddress": "0x00",
"DeviceTemplateId": 190000,
"Parameter": [
190000,
190001,
190002,
190003,
190004,
190007,
190011,
190012,
190014,
190015,
190016,
190019,
190020,
190021
]
},
{
"ReadBusAddress": "0x8",
"DeviceTemplateId": 180000,
"Parameter": [
180177,
180178,
und anhand der Bus-Adresse und des jeweiligen Parameters, macht ism7mqtt daraus dann den entsprechenden MQTT Topic und sendet diesen an den MQTT Broker. Unter HA wäre das dann z.B. so ein Sensor:
sensor.wolf_cgb2_0x03_180006_warmwassertemperatur
Ein Switch für HA - hier z.B. der für den Schalter 1 x Warmwasser - sehe dann z.B. so aus:
switch.wolf_bm2_0x30_220042_1x_warmwasser
und findet sich in der *.json Datei dann z.B. da wieder:
{
"ReadBusAddress": "0x35",
"DeviceTemplateId": 220000,
"Parameter": [
220091,
220001,
220095,
220103,
220104,
330000,
330001,
220107,
330002,
220108,
330003,
330004,
330005,
330006,
330007,
220021,
330008,
220022,
330009,
220023,
330010,
220117,
330011,
220025,
220026,
220027,
220028,
220029,
220030,
220031,
220032,
220033,
220126,
220034,
220035,
220129,
220130,
220040,
220134,
220042,
220043,
220044,
220045,
220046
]
},
Im MQTT Explorer sieht das dann z.B. so aus:
Mehr kann ich Dir dazu dann leider auch nicht sagen.
VG Jim
Also ich hab jetzt einfach mal den ESP mit der ebus-Adaptersoftware auf mein zwar erweitertes, aber mit noch vorhandenem ebus-Schaltungsteil gesteckt. Wie gut wenn man sich das aufhebt. Nur ebusd musste ich in HA neu anlegen hatte ich zwischenzeitlich gelöscht.
Als Configs hab ich die von andre217 genommen. Das sah erstmal ziemlich ernüchternd aus, aber zumindest war klar das etwas ankommt. Habe begonnen den alten archivierten Config-Kram einzupflegen und bin dabei immerhin weiter gekommen. Könnte was draus werden, auch wenn viel dabei ist was es bei mir gar nicht gibt, nur kryptisch bezeichnet ist, oder die Formate nicht stimmen. In HA taucht bisher nur ein geringer Teil auf, das was unter dem Topic hc zu sehen ist, egal, erstmal alle Configs funktionabel einpflegen, dann weitersehen.
Das sieht doch schon gut aus. Bin gespannt.
Beste Grüße
@ch888 : darf ich fragen was du für eine Heizung hast? Ich habe eine Wolf CGS24-200 auch aus dem Jahr 2006.Läuft bisher tadellos, aber auch erst, seit ich die Parameter Stück für Stück angepasst habe.Der erste Heizungsbauer (der sie eingebaut hat) hat lediglich den hydraulischen Abgleich gemacht, der zweite hat zumindest versucht was einzustellen. Ich war es aber irgendwann leid, weil sie nicht so wirklich Lust hatten und es immer an der Zeit gescheitert ist. Also habe ich selber recherchiert, eingestellt - und nun läuft sie perfekt. Und nun möchte ich mich - nach dem Winter - auch mit den ebus Adapter beschäftigen. Liegt schon ein paar Tage hier rum…und wenn jemand eine ähnliche Heizung hat, wäre das ja schon mal eine Erleichterung.
Ich hab einen Oelkessel mit einer Regelung R3, einem BM und einer Mischerbaugruppe - alles von Wolf. Der bivalente 300l Boiler war nach 15 Jahren undicht und wurde durch einen einfachen 200l ersetzt. Die Heizung selber laeuft seit 2006 problemlos - ich hab nur die Pumpen tauschen lassen.
Mit dem ebusd teste ich noch … ich hab der Einfachheit halber alles in eine CSV Datei gepackt und alle anderen deaktiviert. Ziel war erstmal nur Lesen und da hab ich jetzt schon fast alles, was ich brauche.
Hier mal ein Screenshot - ist allen noch rudimentaer (Test wie gesagt):
Das habe ich zum Anlass genommen mir das noch mal genauer anzusehen. Ich hatte zwar gesehen das man im Webinterface der Adapterfirmware etwas an den ESP-Pins herumstellen kann, aber ausser einfachen Zuordnungen der benutzten Pins (UART und LED) dahinter keine weitere Funktionalität erwartet und auch nichts gesehen was darauf hindeutete.
Auf der Website ist es dann aber erwähnt, man könne Sensoren anschliessen die nach Neustart erkannt würden. Nach etwas suchen findet man dann an anderer Stelle, das aktuell wohl nur 1Wire-DS18 gehen sollen die nach Erkennung dann irgendwie im Web-IF angezeigt werden.
Habe dann herumgespielt, gesehen dass man auch I2C zuordnen kann und dem Bus an meinem Adapter zugeordnet. Angezeigt wurde mir nichts, aber ich fand in der REPL-Konsole Befehle für I2C 
Mal sehen ob man die Dinger dann irgendwie über 20-30 Protokollebenen doch von HA auslesen lassen kann
Die 1-wire Sensoren sollten eigentlich auch via MQTT ge-published werden:
Hast Du MQTT am eBUS Adapter Shield selber aktiviert - und nicht nur ueber den ebusd?
Ich habe halt keine 1-Wire Sensoren, werde aber mal welche bestellen weil die auch bei ein paar Shelly-Produkten als einzig nutzbares genannt werden. Vermutlich bezieht sich die Angabe bei ebusd.eu auf dieses automatische MQTT-publishing. Ist auch bei mir aktiviert, gab zuerst ein wenig verwirrung weil im Adapter noch “eBusd” als Topic stand, bei der ebusd-Integration “ebusd”.
Aber ich sehe da nichts was sich auf meine Sensoren beziehen könnte.
Mein Selbstbau-Adapter läuft mit einem Mini-C3 mit etwas älterer Firmware von letztem Jahr, ich glaube die war für Shield V5 vorgesehen. Ich sehe auf den ersten Blick nicht worin sich ESP-C3 von C6 gross unterscheidet, C6 ist vermutlich leistungsfähiger.
Bei mir wird der Adapter aus dem eBus versorgt, ich bin da also von der Stromaufnahme eingeschränkt und kann nichts verwenden was dauerhaft oder nur beim Booten zu viel zieht (es gibt da aber noch etwas Luft, wenn ich einen effektiveren 9-24V/5V-Wandler raussuche, da verlässt man aber meist den kostengünsten Bereich)
In der REPL-Konsole sind übrigens neben 1Wire- auch Befehle für BMx280 I2C-Sensoren und ein Display vorhanden. Aber wie schon geschrieben, ich bin skeptisch ob das funktionieren würde. Gelegentliche Bus-Neusynchs wären ja wahrscheinlich kein Problem, irgendeine Timingschwebung die für längere Zeit einen wichtigen Inhalt blockiert schon eher.
i2cbmpe [-?|--help] [-a ADDRESS]
Read BME280/BMP280 values through the I2C bus
-a, --address=ADDRESS address of the chip instead of 118 (0x76)
i2cssd [-?|--help] [-lrf01] [<text>] [-x POS] [-y POS] [-w PIXEL] [-h PIXEL] Send text to SSD1306
-l, --line Draw a line
-r, --rect Draw a rect
-f, --fill Fill a rect
<text> Write text
-x, --xpos=POS X position
-y, --ypos=POS Y position
-w, --width=PIXEL width (if other than 128)
-h, --height=PIXEL height (if other than 64)
-0, --off Turn display off
-1, --on Turn display on
onewire [-?|--help] [-s] [PIN]
Read 1-wire devices
PIN IO pin number, or read all
-s, --scan scan devices
Meine Idealvorstellung wäre halt ein irgendwie per ESPHome (und vielleicht andere Plattformen) zulinkbares ebusd-SW-Modul, meinetwegen als Binary und gegen Obulus, aber mit dem Rest (konkretes ESP-Modell, z.B. 2-Core) an HW und SW will ich mich dann frei austoben können.
Sonst hab ich bald so viele ESPs in der Bude, dass ich keine Heizung mehr brauche, sondern eine Kühlung für den Sommer
Ja, ist aber mühsam. Auch der gesammelte alte Config-Kram hat seine Tücken (z.B. Stunden für eine Uhrzeit als Temperatur definiert, 12Uhr sind da 1,2°C) und die wolf.json hilft auch nicht immer weiter, viele IDs tauchen da gar nicht auf.
Das mit dem r1-9 als Pollpriorität geht irgendwie auch nicht, alles wird immer alle 10min gelesen, der r(x) wirkt höchsten so dass noch mal zusätzlich davon unabhängig gelesen wird. Kann man vermutlich irgendwo in der ebusd-Konfig einstellen.
Einiges ist hier auch nicht erkennbar, weil Minmalausstattung CGU mit BM0, scheint keinen Mischer zu geben. Aber so nach und nach werden wohl zumindest die wichtigen Parameter erscheinen. Rücklauftemp hab ich bis jetzt noch nicht sehen können.
Wenn es wie bei Tasmota oder ESPhome ist, dann tauchen Werte fuer Sensoren erst auf, wenn sie angeschlossen und erkannt worden sind. Bei Gelegenheit haeng ich mal ein paar DS18B20 dran und berichte.
Ich hab mittlerweile eine Menge ESPs - vor allem die 8266&Co. Die sind so billig und sparsam, da hab ich lieber fuer jeden Zweck einen … Stichwort “dependency hell”.
Ich vermute sogar, dass die nicht nur unvollstaendig, sondern teilweise falsch ist. Als ich druebergefallen bin, dachte ich dass sich das 1:1 in commands (bzw die CSV) umsetzen liesse. Aber solange sich nicht jemand meldet, der wirklich weiss wie Wolf das implementiert hat, geht das nicht. Ich sammle lieber die messages auf dem Bus und versuch weiter sehen, was sich wann aendert.
Kann ich nicht bestaetigen. Ich nehm zwar die meisten Werte aus den Broadcasts (die kommen alle 10/20/30/60sek), aber einige Werte lass ich direkt lesen und am Bus sehe ich ja die Abfrageintervalle.
Kommt wohl auf die verbaute Regelung an - meine R3 kann einen direkten Heizkreis und einen Mischerkreis steuern, auf dem Bus tauchen auch die IDs fuer ein MM (Mischermodul) auf und ich sehe die entsprechenden messages. Ich hab eher zuviele Geraete und versuche herauszufinden, welches Geraet welche Werte sendet (bzw abfragen laesst) und welche Werte ich von welchem Geraet letztendlich im HA verwenden will. Die Aussentemperatur z.B. wird mir von X Geraeten in unterschiedlichen Intervallen und unterschiedlichen Formaten geliefert (0/1/2/3 Dezimalstellen).
Die Ruecklauftemperatur ist bei mir in allen messages “0” - ich vermute, dass meine Mischerbaugruppe gar keinen RL-Fuehler hat … ich sehe ich auch keinen daran.
Jeder Master hat immer auch eine "dedicated slave" adresse : master + 5
#--- Wolf Regelung R3
address 03: master #11
address 08: slave #11, scanned "MF=Kromschroeder;ID= ;SW=0230;HW=0206"
address 10: master #2
address 15: slave #2, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=0184"
#--- Wolf Bedienmodul BM
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=0184"
address 31: master #8, ebusd
address 36: slave #8, ebusd
#--- Wolf Mischermodul MM
address 50: slave, scanned "MF=Kromschroeder;ID= ;SW=0230;HW=0206"
address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0230;HW=0206"
address 70: master #4
address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=0184"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID= ;SW=0204;HW=0184"
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)