Ich hoffe mal, dass mich einer der ebus-"Wissenden" verbessert, wenn das Folgende Unsinn ist, zu CAN s.u.:
1) Die Komponenten "sprechen" untereinander über ein Hardware-Protokoll, das sich "ebus" nennt. @John30 hat dazu einen ersten Adapter entwickelt und eine Software (gesonderter Daemon, der früher nur auf einem Pi oä. lief) geschrieben, die die Daten dann als Serverdienst "zur Abholung" durch andere Software bereitstellt.
Es gibt mind. ein Modul (mit Schwerpunkt auf Thermen eines anderen Herstellers), das diese Daten dann abholen und in FHEM darstellen kann (und ggf. Steuerungsaufgaben übernehmen).
a) Gibt es heutzutage deutlich verbesserte Adapter (zum Selberlöten oder fix und fertig), die man afaik an JEDES Heizungssysten anstöpseln kann, das dieses Protokoll verwendet. Soweit sollte es also klappen (die CAN-Variante aber vermutlich eher nicht)...
b) ist die Software zwischenzeitlich u.A. auch auf ESPxxx portiert und kann die Daten über MQTT bereitstellen, so dass man "relativ einfach" praktisch jede gängige Automatisierungslösung dranflanschen kann...
c) gibt es dabei aber zwei Haken!!!
aa) damit die Software ordentlich läuft, muss man ihr mitteilen, was wo an Infos/Daten/Komponenten vorhanden ist, und wie ggf. dann auch gelesen und geschrieben werden kann. Die dafür erforderlichen Files sind afaik (v.a. für Weishaupt!) von ziemlich unterschiedlicher Qualität und das Zusammenspiel auch eher schwierig bis sehr schwierig zu verstehen.
bb) Sind die per MQTT bereitgestellten Daten auch eher in einer Art "Roh-Format" und bedürfen (für eine sinnvolle Verwendung in FHEM) ebenfalls einer "speziellen" Behandlung
(Wer einen etwas detaillierteren Eindruck davon haben will: Es gibt einen Thread vom User rob zu Weishaupt+MQTT).
Wenn dieser Weg beschritten ist, ist man "direkt" in der Heizung "drin" und hat prinzipiell auch Zugriff auf alle Optionen, die verfügbar sind (also ggf. auch solche, die der Hersteller sonst nicht "zeigt").
Dass sich bisher hier kein Weishaupt-User gemeldet hat, dürfte mit zwei Aspekten zusammenhängen:
- Die konkrete Hardware scheint neu zu sein => die Wahrscheinlichkeit ist hoch, dass man erst die "Decodier- und Zuordnungsfiles" erstellen muss (und ich glaube nicht, dass da einer Lust hat, per Fernwartung zu unterstützen).
- es gibt nicht so viele User, die überhaupt Weishaupt haben
2) Alle anderen Lösungen scheinen vorauszusetzen, dass die (vom Hersteller dafür vorgesehenen) Daten bereits über eine andere Schnittstelle irgendwo decodiert liegen.
Anders gesagt: Man sollte entweder
- vorher die Zusage des Herstellers haben, dass man Info bekommt, wie die Datenfelder/Adressen auf dem Bus zu verstehen sind (hahaha), dann geht ebus;
- hartnäckiger Tüftler sein, der "es wissen will" (und sich die notwendigen Kompetenzen aneignen);
oder
- einen anderen Hersteller wählen, bei dem die grundlegenden Arbeiten (File-Erstellung) bereits weiter vorangeschritten sind (und es mehr Leute gibt, die helfen können).
Sonst ist jedenfalls die "ebus-Adapter"-Lösung (auf der Basis von @John30) nicht das richtige...
Soweit mein Kenntnisstand zum Thema ebus.
Ob sich der prinzipielle Befund verbessert, wenn eine andere (?) Art der _hardwareseitigen_ Kommunikation stattfindet, sei mal dahingestellt. CAN ist an sich "auch nur" irgendein Industriestandard, und die erste Hürde ist dann eigentlich immer, die Daten überhaupt lesen zu können - also einen "computerverträglichen" Signalpegel hinzubekommen und ggf. dann auch was schreiben zu können. Kann sein, dass man dafür statt des ebus-Adapters einfach "irgendeinen CAN-Bus-Adapter" nehmen könnte (wie das dann anzusprechen wäre, ist eine zweite Frage) Ob und in welcher Weise sich die eigentliche Adressierung unterscheidet, wäre eine weitere Frage, wobei ich tippen würde, dass an dieser (letzten) Stelle keine Revolution stattgefunden hat.
Die per CAN übertragbaren Datenraten sind afaik höher, und der "alte" ebus kommt schon uU. aus dem Tritt, wenn man viele Anfragen darauf absetzt. Von daher wäre CAN vermutlich der "modernere" Standard.
Hoffe, das hilft irgendwie weiter mit der Entscheidungsfindung

.