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.