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.

[coko]

Ich freue mich über jegliche Art von Feedback!

Schön, dass Du Deine Umsetzung hier teilst! Ich habe mal einen ersten Blick drauf geworden. Siehe nachfolgende Anmerkungen. Werde das eher knapp halten, gerne nachfragen falls das so nicht reicht.

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.

Die Abtrennung eines eigenen OFMs ist dann sinnvoll, wenn eine Anwendung in mehreren OpenKNX-Applikationen zu erwarten ist. Hier würde ich das eher nicht erwarten, daher kannst Du da bis auf weiteres drauf verzichten.

Gibt es ansonsten Gründe für die anderen Abweichungen von der üblichen OpenKNX-Projektstruktur/-Konventionen?

Zum ETS-Teil:

• Standard-Werte brauchst Du nicht im Text angeben. Die zeigt die ETS auch so an.
• Wozu Enum-Typ bei der HW-Adresse?
• Überschriften entsprechend auszeichen (UIHint"Headline")
• Warum Wartungszeiten in Wochen (und nicht in Tagen?)
• Sende-Intervalle am besten frei einstellbar machen
• Modul-Icon wäre noch optisch nett
• Kontext-Hilfe wertet die Oberfläche auf

Firmware:

• OpenKNX Logging Makros nutzen (logInfoP et al.). Damit bekommst Du dann auch automatisch den Modulnamen als Präfix
• Laufen die Schnittstellen-Abfragen das Event-Handling auf einem anderen Core? (Das Schreiben auf KOs darft nicht von verschiedenen Kernen erfolgen, der Steck unterstüzt keinen nebenläufigen Zugriffe)
• Warum Parameterzugriffe in ifdefs? Du kannst doch erwartetn, dass die Zugriffsmakros immer verfügbar sind.

Weitere:

• Modul-Präfix?

[alanz]

Behaltet allerdings im Hinterkopf, dass der im Git Repo beschriebene Aufbau keine galvanische Trennung zwischen Hoval und KNX bietet.

Damit solltest du sehr vorsichtig sein. Bei mir gibt es einen erheblichen Potential-Unterschied (> 50V) zwischen Masse des Hoval-Busses und KNX und die KNX Seite verhält sich dem Hoval Bus gegenüber eher wie ein AC Signal (beide Adern parallel so das diese gegeneinander wieder DC sind). Ich hatte zunächst mit einem ISO1050 für die galvanische Trennung gearbeitet, der mochte das gar nicht und hat größtenteils Mist geliefert sobald er mit beidem verbunden war.

[mags]

@coko: Danke schonmal für das erste Review! Da habe ich etwas mehr zu tippen, dazu komme ich vermutlich erst heute Abend.

@alanz: Ebenfalls danke für den Hinweis. In meinem Aufbau ist Hoval-GND nicht verbunden. Zwischen REG1-GND und CAN-H bzw. CAN-L messe ich jeweils 1,8V. Das und die Tatsache, dass der Aufbau auch über längere Zeit stabil ohne Übertragungsfehler läuft hat mich erstmal etwas beruhigt. Aber ich habe in dieser Richtung auch nicht so viel Wissen und Erfahrung. Von daher bin ich froh, über jede Einschätzung die ich dazu von euch bekomme.

[Ing-Dom]

Von daher bin ich froh, über jede Einschätzung die ich dazu von euch bekomme.

Um mal schnell was zu basteln mag das für einen kurzen Zeitraum ok sein, wenn man vorher den Potentialunterschied gemessen hat und SELV sicherstellen kann.

Produktiv würde ich aber massiv davon abraten und von einem Test-Dauerbetrieb auch.
Ein wenig galvanische Trennung ist weder kompliziert noch teuer.
ein adum1201 oder ähnlich reicht hier und die hoval liefert auch 24v.
d.h. 24v => 3.3V wandler dazu und ein adum1201 zwischen SN65HVD230 und dem reg1 controller.

[mags]

Ing-Dom: Danke, die zusätzlichen Bauteile sind bestellt.

coko: Dein Feedback zum ETS Teil ist umgesetzt, besten Dank. Falls du noch einen Blick darauf werfen möchtest: https://github.com/maxarndt/openknx-...gateway/pull/2
Die Wartungszeiten sind in Wochen, weil sie in dieser Einheit von der Hoval Anlage übertragen werden. Ich habe auf eine Umrechnung in Tagen verzichtet, weil das eine Genauigkeit suggeriert hätte, welche der Wert nicht hat.

Die Abfragen und das Event-Handling laufen auf einem Core, hier gibt es derzeit keine Nebenläufigkeit.
Die restlichen Anmerkungen machen auch absolut Sinn, besten Dank! Es gibt meist keinen tieferen Grund für die getroffenen Entscheidungen. Ich habe große Teile generieren lassen und bisher noch nicht jede Entscheidung hinterfragt.

Falls du mit den Abweichungen von der bisherigen Projektkonvention z.B. den Einsatz von uv gemeint hast, hier bin ich es gewohnt die Abhängigkeiten der Build Umgebung möglichst gut im Projekt selbst zu definieren und nicht vom globalen Tooling des entsprechenden Computers abhängig zu sein.

Zum Firmware Teil folgen noch Anpassungen in der nächsten Zeit.

[coko]

coko: Dein Feedback zum ETS Teil ist umgesetzt, besten Dank.

Gerne, wenn es als nützlich wahrgenommen wird.

Falls du noch einen Blick darauf werfen möchtest: https://github.com/maxarndt/openknx-...gateway/pull/2

Kann ich machen, allerdings noch nicht versprechen wann. Weitere Anmerkungen würde ich dann direkt im PR anhängen?

Die Abfragen und das Event-Handling laufen auf einem Core, hier gibt es derzeit keine Nebenläufigkeit.

Das macht es einfacher. Wobei man dann auch noch mal schauen sollte wie lange die Kommunikation maximal im Loop-Aufruf benötigt. Dazu verweise ich schon mal auf die Diagnosemöglichkeit mit OPENKNX_RUNTIME_STAT siehe z.B. https://knx-user-forum.de/forum/proj...ll#post2054754 wobei da mit ESP32 die Anzeige der Kern-Zuordnung etwas gewöhnungsbedürftig ist.

Falls du mit den Abweichungen von der bisherigen Projektkonvention z.B. den Einsatz von uv gemeint hast, hier bin ich es gewohnt die Abhängigkeiten der Build Umgebung möglichst gut im Projekt selbst zu definieren und nicht vom globalen Tooling des entsprechenden Computers abhängig zu sein.

Da gibt es noch einige Abweichungen von der üblichen OpenKNX-Projektstruktur. Ggf. braucht es eine kleine Einführungs-Session dazu; das ließe sich auch mal einrichten.