OpenKNX REG1 CAN-Bus Applikationsplatine & Hoval Applikation/Firmware

[mags]

Um für die Steuerung meiner Hoval Lüftungsanlage nicht auf teure, proprietäre Komponenten angewiesen zu sein, arbeite ich an einer OpenKNX basierten Lösung.

OpenKNX REG1 CAN-Bus Applikationsplatine

Ziel ist, auf Basis des OpenKNX REG1 eine Applikationsplatine mit einem CAN-Bus Transceiver zu entwickeln.
Mit dieser Applikationsplatine können dann verschiedenste Lösungen geschaffen werden, so wie ihr es von den bestehenden OpenKNX Komponenten gewohnt seid.

Danke an dieser Stelle schonmal an Ing-Dom für die Vorarbeit und die bisherige Kommunikation zu diesem Vorhaben, sowie der restlichen OpenKNX Community!

Als Software-Engineer fühle ich mich vor allem beim zweiten Teil dieses Vorhabens wohl, daher die Frage an euch: Gibt es Leute unter euch, die bei der Entwicklung dieser Platine unterstützen können und möchten? Ich würde mich jedenfalls freuen!

Bedingt durch andere Open Source Projekte im Umfeld von Hoval Steuerungen plane ich die Umsetzung mit einem ESP32. Als CAN Transceiver verwende ich derzeit einen SN65HVD230 auf meinem Breadboard. Gebt mir gerne Feedback, falls ihr einen anderen Transceiver favorisiert.
Hoval setzt auf RJ45 als Steckverbinder für ihren CAN Bus. Aus Platzgründen im REG1 und vermutlich auch allgemein für andere CAN Vorhaben, könnte ein anderer Stecker aber mehr Sinn machen. Dies kann noch entschieden werden.

OpenKNX Hoval Applikation

Für die beschriebene Hardware, werde ich eine OpenKNX basierte Applikation für meine Hoval HomeVent Lüftungsanlage entwickeln.

Das Hoval Toptronic(?) CAN Protokoll wurde bereits reverse-engineered und es gibt mehrere Implementierungen in verschiedenen GitHub Projekten, was natürlich hilfreich für dieses Vorhaben ist, z.B. zittix/Hoval-GW, nliaudat/esp_canbus

Priorität für mich hat im ersten Schritt das Auslesen der Sensorwerte wie VOC und Feuchte, wie auch das Steuern der Lüfterleistung und der gewünschten Luftfeuchtigkeit.
Da dieses CAN Protokoll von Hoval auch in deren anderen Produkten verwendet wird, ist natürlich auch eine Erweiterung für andere Steuerungen (Heizung, etc.) denkbar.

Feedback

Ich freue mich über Feedback zu diesem Vorhaben und bin gespannt, was die OpenKNX Community dazu sagt.

Impressionen

Hier noch zwei Fotos meines Proof-of-Concepts mit der Hoval Steuerung:

IMG_2531.jpgIMG_2534.jpg


Frohe Ostern!

Beste Grüße,
Max

[Ing-Dom]

Danke an dieser Stelle schonmal

Gerne, und freut mich wenn es angenommen wird.

Gibt es Leute unter euch, die bei der Entwicklung dieser Platine unterstützen können und möchten?

Werde auf jeden Fall unterstützen

Bedingt durch andere Open Source Projekte im Umfeld von Hoval Steuerungen plane ich die Umsetzung mit einem ESP32. Als CAN Transceiver verwende ich derzeit einen SN65HVD230 auf meinem Breadboard. Gebt mir gerne Feedback, falls ihr einen anderen Transceiver favorisiert.

Also, wie schonmal erwähnt braucht es zwischen CAN und KNX-TP auf jeden Fall eine galvanische Trennung.
Wenn man ESP + LAN (ohne TP) machen will, käme man ohne aus, aber das halte ich nicht für zielführend.
Ich würde hier lieber eine universell einsatzbare CAN-Platine designen, die auch mit KNX-TP funktioniert.

1) Man könnte einfach zu dem SN65HVD230 einen 2kanal Digitalisolator packen (zB Adum1201). Git verfügbar, günstig.
Für die Versorgung der Sekundärseite braucht es noch einen DC/DC oder man versorgt extern (unschön).

2) zu dem SN65HVD230 einen 2kanal Digitalisolator mit "Isopower" packen

3) man verwendet einen integrierten isolierten CAN Transceiver, zB Adum 3053. Das wäre meine Vorzugslösung.

Ich gehe mal in mich..

Hoval setzt auf RJ45 als Steckverbinder für ihren CAN Bus. Aus Platzgründen im REG1 und vermutlich auch allgemein für andere CAN Vorhaben, könnte ein anderer Stecker aber mehr Sinn machen. Dies kann noch entschieden werden.

wenn man einen ungeschirmten 8P8C Stecker (ohne Leds und Magnetics) verwendet, dann sind die auch niedriger und passen.
Trotzdem macht ggf. die Standardmäßige steckbare Schraubklemme mehr Sinn, da universeller.

[Sisamiwe]

mags

Schau mal hier https://knx-user-forum.de/forum/proj...-f%C3%BCr-reg1
Da gibt es auch eine Anwendung für CAN.

[alanz]

Hallo mags,

ich beschäftige mich schon länger mit dem Thema Hoval TopTronic und KNX. Ich hatte mich vor drei Jahren zum ersten Mal mit dem Thema beschäftigt und auch das Protokoll größtenteils selbst reverse-engineered. Das lag dann aus Zeitgründen länger rum und hat Staub angesammelt. Diesen Winter habe ich das dann wieder ausgegraben. Mittlerweile habe ich eine "alpha" Version bei mir seit Dezember im Betrieb. Diese emfängt die Daten vom Hoval CAN Bus und schickt sie an den KNX Bus weiter. Mit der Schreibrichtung hatte ich auch schon mal begonnen, bisher aber noch nicht die Zeit gefunden das weiter zu treiben.

Wo ich gerade stehe:

• Ich habe mir entsprechende Hardware entwickelt, basierend auf einem Seeeduino XIAO RP2040, MCP2515, ADuM1201 und und MCP2562 + noch ein paar weitere Teile da ich unter anderem noch zwei BME680 und eventuell einen SPS30 verbauen will. Die Platine passt in eine StrapuBox 2062. Die Bauteilauswahl basiert auch darauf was ich hier rumliegen hatte.
• Ich habe einen Dekoder für die Kommunikation mit dem Hoval Bus geschrieben. Dieser dekodiert die Nachrichten und schickt sie weiter. Auch das kodieren ist hier schon umgesetzt, aber noch nicht gut getestet. Der HovalBus hat noch einige speziellere Nachrichten die ich noch nicht verstanden habe. Aber das grundsätzliche Lesen und Schreiben funktioniert.
• Ich habe um den Dekoder eine OpenKNX Applikation gebaut, welche die Standard-Dinge wie Temperatur, Luftfeuchtigkeit, Betriebsmodus, etc. auf den Bus schreibt. Hier ein Auszug der KOs und der Applikation:
  grafik.pnggrafik.png

Was mir noch fehlt ist wie gesagt das schreiben, sowie ein paar Merkwürdigkeiten im Protokoll von Hoval die ich noch nicht verstanden habe. Das Protokoll verwendet CAN nur als "Transportmedium" hat sonst aber meinem Verständnis nach wenig mit Standard-CAN-Protokollen zu tun. Mache Dinge sind auch meinem Verständnis nach eher merkwürdig von der Umsetzung.

Falls du Interesse hast, würde ich anbieten, das ich meinen aktuelle Stand die nächsten Tage mal bereinige und in ein öffentliches Repository schiebe. Auch von den (unbestückten) Platinen habe ich noch 3 oder 4 rumliegen, die ich bei Interesse abgeben würde (Schaltpläne würde ich mit ins Repository legen).
Sowohl der Code als auch die Hardware kann noch einiges an Feinschliff vertragen. Man merkt beidem sicher an, das ich weder viel Erfahrung mit der Hardwareentwicklung noch mit C++ und Microcontrollerprogrammierung habe (ich bin eigentlich Java Programmierer, was man dem Code auch anmerkt).

Beste Grüße.

[c4orbi]

Ich bin an einer Lösung interessiert, denn hier ist eine FRT 451 verbaut.

[mags]

Falls du Interesse hast, würde ich anbieten, das ich meinen aktuelle Stand die nächsten Tage mal bereinige und in ein öffentliches Repository schiebe.

Stark! Gerne, vor allem bei der Implementierung des Hoval Protokolls können wir sicherlich voneinander profitieren.

[Ing-Dom]

wenn ihr hier ne gute Lösung für die FW auf die Beine stellt kann ich gerne bei der HW unterstützen.

[Sisamiwe]

wenn ihr hier ne gute Lösung für die FW auf die Beine stellt kann ich gerne bei der HW unterstützen.

Für die Ledatronic habe ich schon eine Firmware, aber ich scheitere an der ETS-Applikation.
Hier bräuchte ich Unterstützung

[mumpf]

Da sollten wir vielleicht Mal telefonieren. Da bin ich geūbt drin, Starthilfe zu geben...

Gruß, Waldemar

[Sisamiwe]

Da sollten wir vielleicht Mal telefonieren. Da bin ich geūbt drin, Starthilfe zu geben...

Gruß, Waldemar

Sehr gern. Ich melde mich

[alanz]

Stark! Gerne, vor allem bei der Implementierung des Hoval Protokolls können wir sicherlich voneinander profitieren.

Ok ich werde das ganze die nächsten Tage mal aufräumen und versuchen die eventuell verwirrenden Tests, Zwischenstände, etc. aufzuräumen. Danach stelle ich das in ein GitHub Repository. Würde mich freuen, wenn wir hier zusammen was Gutes auf die Beine gestellt bekommen.

wenn ihr hier ne gute Lösung für die FW auf die Beine stellt kann ich gerne bei der HW unterstützen.

Gerne. Meine Lösung ist bisher eher rudimentär und basiert auf dem, was ich hier von anderen Projekten so rumliegen hatte. Ist definitiv nicht optimal.

[coko]

Meine Lösung ist bisher eher rudimentär und basiert auf dem, was ich hier von anderen Projekten so rumliegen hatte. Ist definitiv nicht optimal.

Wenn Interesse besteht, dann führe ich da gerne auch mal ein Review durch und kann auf der Basis Tipps zur Optimierung geben.

Sollten wir dann aber schauen, dass wir das koordiniert angehen, damit nicht an 3 Stellen aneinander vorbei entwickelt wird, was am Ende vielleicht eher zur Frustration führt. Mein aktueller Stand auf Basis dieses Theads sieht wie folgt aus (ich bitte ggf. um Korrektur falls das ich etwas nicht korrekt wiedergebe!):

• mags hat einen HW-Prototypen entwickelt und braucht noch eine ETS-Applikation. Ing-Dom hat für HW-Entwicklung schon Support angeboten.
• Sisamiwe hat Firmware (CAN universal?) und braucht auch noch eine ETS-Applikation mumpf hat eine Einführung in die Applikationsentwicklung angeboten
• alanz hat schon eine Firmware und ETS-Applikation (speziell für Hoval), sieht aber noch Optimierungsbedarf coko bietet ein Review an

Im Idealfall (ob realistisch und sinnvoll kann ich aktuell noch nicht beurteilen) bekommen wir damit gemeinsam am Ende bis zu 3-Hardware-Varianten (zur Abdeckung unterschiedlicher Anwendungsfälle) und 2-Firmware/Applikations-Varianten (CAN Universell + Spezifisch für Hovac), die kombinierbar sind.