OpenKNX REG1 CAN-Bus Applikationsplatine & Hoval Applikation/Firmware

[Ing-Dom]

Gemini:

Im Bereich der Gebäudeautomation ist CAN FD (Flexible Data-Rate) aktuell noch ein absoluter Exot. Nahezu alle relevanten Partnergeräte arbeiten mit Classic CAN (CAN 2.0A/B).

Hier ist eine Analyse für Ihre Hardware-Entwicklung:



1. Warum Classic CAN (2.0B) ausreicht

Die oben genannten Systeme (Hoval, Stiebel Eltron, Wilo, GEZE) sind auf Langlebigkeit und einfache Verdrahtung ausgelegt.

• Baudraten: Die meisten HLK-Hersteller (wie Hoval/TopTronic E) nutzen Standard-Baudraten von 10 kbit/s bis 125 kbit/s (selten 250 oder 500 kbit/s).
• Nutzlast: Da meist nur Sensorwerte (Temperatur, CO2, Druck) oder Stellbefehle übertragen werden, reichen die 8 Bytes eines Standard-CAN-Frames völlig aus.
• Leitungslänge: In Gebäuden sind oft lange Leitungswege nötig. Classic CAN ist hier bei niedrigen Baudraten robuster als CAN FD.

2. Mögliche Partner für CAN FD (Zukunftsszenarien)

Falls Sie Ihr Gateway zukunftssicher oder für High-End-Anwendungen auslegen wollen, sollten Sie CAN FD nur für folgende Nischen in Betracht ziehen:

• Aufzugstechnik: Moderne Aufzugsteuerungen (z.B. über das Protokoll CANopen Lift) könnten bei sehr hohen Gebäuden und komplexen Gruppensteuerungen auf CAN FD setzen.
• EV-Charging (V2G): Bei der Kommunikation zwischen Ladestation und Fahrzeug (ISO 15118-20) oder innerhalb großer Batteriespeicher-Cluster wird CAN FD diskutiert, um Firmware-Updates oder komplexe Zertifikate schneller zu übertragen.
• Automotive-Integration: Wenn Ihr Gateway als Brücke dient, um Fahrzeugdaten (z.B. im Smart Home integrierte Tesla-Wallboxen oder Fahrzeug-Telemetrie) nativ abzugreifen.

3. Empfehlung für Ihre Hardware-Spezifikation

PHY	High-Speed CAN-Transceiver (abwärtskompatibel zu Low-Speed/Fault-Tolerant ist meist nicht nötig).
Protokoll	CAN 2.0B (unterstützt 11-Bit und 29-Bit Identifier).
Isolation	Zwingend erforderlich. In Gebäuden mit unterschiedlichen Potenzialen (Heizungskeller vs. Elektroverteiler) ist eine galvanische Trennung zwischen KNX und CAN essenziell.
Terminierung	Schaltbarer 120 Ohm Widerstand (per Jumper oder Software), da Ihr Gateway oft am Leitungsende sitzt.

Fazit: Ein Fokus auf CAN FD ist für die aktuelle Gebäudeautomation nicht notwendig. Viel wichtiger für den Erfolg Ihres Produkts wäre die softwareseitige Unterstützung von CANopen oder die einfache Implementierung von proprietären Identifier-Listen (wie sie Hoval oder Buderus nutzen).

[cad435]

Also das einzige überhaupt "erachtenswerte" Szenario wäre wohl das mit dem EV-Charging...
ob die Ladestationen die auf CAN-FD setzen dann in unserem Umfeld Verbreitung finden wage ich zu bezweifeln.

Denke die meisten Leute die sich für Dinge wie OpenKNX interessieren werden sich eher eine Ladestation anschaffen die "einfacher" zu integrieren ist.


Von daher würde ich wahrscheinlich weitermachen wie bisher, erstmal den "leichteren" weg gehen, Erfahrung sammeln, sollte die Notwendigkeit nach CAN-FD auftauchen, kann man immer noch ein FD-Gateway entwickeln.

[Sisamiwe]

Hallo,
ich "meine" Anwendung mit der LEDATRONIC ist Classic CAN mit 125kbps

[alanz]

Hallo zusammen,
ich wollte den Thread mal wieder ausgraben und ein Update zu meinem Stand meiner Hoval TopTronic anbindung geben:
Ich habe gerade einen PR gegen mein Repo erstellt. Der PR fügt primär die Möglichkeit hinzu Nachrichten vom KNX Bus auf den Hoval Bus zu schicken. Damit kann man die Lüftung jetzt über KNX Steuern (und nicht nur wie bisher den Status auslesen). Bisher ist das senden von einfachen ein und zwei Byte Nachrichten umgesetzt. Es ist mir auch gelungen, das CRC Polynom für die Multi-Part Messages zu identifizieren. Damit wäre jetzt auch ein senden von Nachrichten mit mehr als 2 Bytes möglich. Das ist bisher aber noch nicht umgesetzt, da ich noch keinen Anwendungsfall dafür habe.

Das ganze läuft bei mir jetzt seit mehreren Wochen produktiv. Ich steuere über den Bus den Betriebsmodus (Standby, Woche 1, Woche 2, Konstantbetrieb, ...) und den Party / Pause Modus. Mit letzterem bin ich noch nicht glücklich, da Hoval nur eine Addresse für den Wert für beides Party und Pause hat und Party / Pause dann nur die Anzeige und die Dauer steuert. Da werde ich definitiv noch was ändern / verbessern. Ansonsten bin ich ganz zufrieden mit dem aktuellen Stand.

Gruß

[c4orbi]

Welche Hardware verwendest du?

[alanz]

Welche Hardware verwendest du?

Meine Eigene, die auf den Hoval Use-Case zugeschnitten ist. Schaltplan etc. findet sich im Repo (https://github.com/Blizzard26/OAM-KN...ain/schematics). Basiert auf einem XIAO RP2040, MCP2515, MCP2562 + ADuM1201 für die galvanische Trennung. Spannung für die CAN-Seite kommt vom Hoval Bus. Die Hardware hat sicher jede Menge Optimierungspotential (basiert auf dem was ich in der Werkstatt rumliegen hatte). Ich hatte mir damals 5 Stück von JLCPCB machen lassen (unbestückt, nur die Platine). 3 davon liegen noch rum. Falls jemand Interesse hat gebe ich die gerne im Ausgleich für die Versandkosten ab.

[mags]

Hallo zusammen,

nach längerer Zeit mit anderen Prioritäten gibt es mittlerweile ein paar Ergebnisse, die ich gerne mit euch teile.

Bei mir läuft nun ebenfalls die Steuerung der Hoval Lüftungsanlage via KNX. Wie ursprünglich geplant, kommt bei mir die REG1-LAN-TP-Base Hardware von Dom zum Einsatz. Derzeit mit einem SN65HVD230 CAN Modul.

IMG_0036.jpg

Das Ganze läuft jetzt seit etwas über einer Woche und tut was es soll.

Auf ausgewählten Touch Displays im Haus lässt sich die Anlage nach den Möglichkeiten derer Applikation steuern.
Aktuell bereite ich noch eine Contribution für das OFM-SmartHomeBridge vor, damit die Unterstützung von Lüftungsgeräten im Rahmen der Apple HomeKit Spec erweitert wird. Derzeit ist hier nur ein binäres An- und Ausschalten implementiert.

Am ein oder anderen Tag als ich mit der Entwicklung weiter gemacht habe, kam es zu CAN-Bus-off Zuständen. Diese Fehler konnte ich bisher nicht zuverlässig reproduzieren. Da diese nach dem Überprüfen/Wackeln an den Jumperkabeln auf meinem Breadboard nicht weiter auftraten, ist meine bisherige Vermutung, dass dies wahrscheinlich meinem Testaufbau geschuldet ist.
Ich werde die Thematik jedenfalls weiter im Auge behalten.

Da es die Entwicklung vereinfacht, habe ich derzeit nur ein Git Repo und keine Trennung wie hier üblich nach OFM sowie OAM. Das würde ich aufteilen, wenn das Projekt als Mehrwert für die OpenKNX Community gesehen wird.

Hier kann sich gerne jeder einen Eindruck darüber verschaffen was das Repo derzeit beinhaltet: https://github.com/maxarndt/openknx-hoval-gateway

Folgender Screenshot gibt noch einen Eindruck welche Parameter und Kommunikationsobjekte bisher existieren:
Bildschirmfoto 2026-08-06 um 17.33.02.png

alanz Danke fürs Teilen deiner Implementierung. Den Party/Pause Modus habe ich beispielsweise noch nicht implementiert und auch Drehzahlwerte der Rotoren gibt es bei mir bisher noch nicht.

Ich freue mich über jegliche Art von Feedback!

Falls es jemanden gibt, der die Firmware ebenfalls bei sich ausprobieren mag, ebenfalls sehr gerne!
Behaltet allerdings im Hinterkopf, dass der im Git Repo beschriebene Aufbau keine galvanische Trennung zwischen Hoval und KNX bietet.