OpenKNX REG1 CAN-Bus Applikationsplatine & Hoval Applikation/Firmware

[coko]

Ich bspw. nutze aktuell ein PiPico mit Ing-Dom BCU-Connector und dieser Waveshare CAN Platine. Es gibt aber sicher auch andere Lösungen wie bspw eine REG1-App Platine

Bei gleichem/kompatiblem Controller (ob es da verschiedene alternative "Standardlösungen" gibt entzieht sich meiner Kenntnis) sollte das auch ganz gut umsetzbar sein. Die Waveshare-Platinen sind grundsätzlich eine Lösung in Kombination mit dem Pico-BCU-Connector. Hast Du da auch ein angepasstes Gehäuse für?

Ich hatte versucht, das LEDA-Protokoll hier zu kapseln

Das hatte ich schon gesehen :-)

[alanz]

mags Ich habe meinen aktuellen Stand jetzt mal aufgeräumt, die commits gesquashed und alles hier nach GitHub gepushed: https://github.com/Blizzard26/OAM-KNX2HovalGateway
Ich habe auch mal noch zusammen mit GitHub Copilot eine halbwegs pasable Readme.md erzeugt.

Ein paar Anmerkungen zum Repo:

• Im Gegensatz zu den anderen OpenKNX Repositories verwende ich derzeit git submodules zum einbinden der Module. Ich entwickle viel unter Linux und da empfinde ich die Powershell Scripte etc. als störend. Daher hatte ich mich für git submodules entschieden. Ansonsten sollte das Analog funktionieren.
• Im Ordner docs gibt es ein AsciiDoc Dokument mit einer Beschreibung des Hoval Protokolls die ich während meines Reverse Engineering erstellt habe.
• Im Ordner schematics liege die KiCad files für das aktuell von mir verwendete Board. Strom für die CAN Seite kommt dabei vom Hoval selbst (der Bietet 12V für das Display).
• Die ApplicationId müsste sicher noch entsprechend der Projektregeln angepasst werden.

Grundsätzlicher Aufbau der Implementierung:

• HovalProtocolHandler Implementiert die Kommunikation über den CAN Bus (Empfangen von Nachrichten, ggf. zusammensetzen der Nachrichten und Parsen entsprechend der Hoval Parameter, sowie senden)
• HovalMessage.h beschreibt die bekannten Nachrichten und wie diese geparsed werden müssen.
• HovalMessageTransformer.h definiert das Mapping der Hoval Nachrichten auf die KNX Datentypen etc.
• HovalGatewayModule implementiert die OpenKNX Seite

coko Ing-Dom Über das angebotene Review würde ich mich sehr freuen.

[coko]

Ich habe auch mal noch zusammen mit GitHub Copilot eine halbwegs pasable Readme.md erzeugt.

Also wenn Du mich fragst: Lieber kürzer und zielgerichtet handgeschrieben, als "passabel" mit ausufernden Details (wie z.B. git als Requirement) die Blick aufs wesentliche verwässern...

Schon mal kurz als erster Eindruck:

• Wenn ich das richtig sehe, dann verwendest Du die vergleichbare Hardware für die CAN-Anbindung wie Sisamiwe (der eine andere Bibliothek verwendet). Du nutzt mit eine leicht angepasste Version einer CAN-Bibliothek https://github.com/Blizzard26/Seeed_Arduino_CAN .
• Im Modul machst Du einige Dinge unnötig kompliziert:
  • Nutzung von loop(configured) statt loop()
  • Wozu readParams ?
  • Zur Ermittlung von Laufzeiten kannst Du auf die Runtime-Statistic-Funktion zurückgreifen, die in OpenKNX-Common enthalten ist.
  • Du schreibst direkt aufs Diagnose-KO? (das wäre unerwartet)

[coko]

Über das angebotene Review würde ich mich sehr freuen.

Fortsetzung (und bitte nicht böse sein, dass ich da nun einfach erst mal eine weitere Liste über den Zaun werfe):

• Du hast noch ältere Modul-Releases im Einsatz
• Zu den git submodules: Hatten wie früher mal evaluiert und uns bewusst dagegen entschieden. Damit ist ggf. auch ein Update auf die jeweils aktuellen v1 Releases einfach möglich
• firmwareRevision sollte über die XML-Definition erfolgen. Das ist wesentlich bequemer und weniger Fehleranfällig. Dazu ggf. mal in aktuelle Releases schauen z.B. StateEngine (da ist es drin)
• Wozu die Serial-Ausgabe in setup()? Für Ausgaben solltest die entsprechenden Funktionen aus Common verwendet werden. Die bilden auch verschiedene Log-Level an und können direkt ein Modul-Präfix ausgeben. Teilweise nutzt Du die auch schon.
• Wozu setup1/loop1? Wenn ich nichts übersehen habe, dann nutzt Du im Modul den zweiten Core nicht. Könnte aber für CAN-Bus-Kommunikation sinnvoll sein.
• Warum die abweichende Struktur der platformio.ini ?
• Nutzung includes: Ziemlich viele und auch solche eigentlich nicht nötig sein sollten. Zum Ausschluss von Mehrfach-Includes steht #pragma once zur Verfügung
• Die Nutzung vom Kürzel LOG/log ist unglücklich, da Verwechslungen mit Logikmodul möglich.
• Jedes Modul benötigt ein eindeutiges Kürzel, das ist auch Voraussetzung für die Funktion vom Config-Transfer. Du hast hier nun HOVAL angegeben. Üblich sind hier Kürzel von 3 Buchstaben, in Einzelfällen haben wir auch mal 2 oder 4. Würde hier aber ungern von abweichen.

[Ing-Dom]

ich hab mir mal ein paar CAN Transceiver angeschaut und leider ist die Stromaufnahme der CAN Transceiver nicht ganz ohne. Bis zu 200mA @5V werden hier veranschlagt (nicht in jedem Zustand, aber max) - das ist deutlich zu viel für Bus-Powered..

[ralf9000]

Braucht der MCP2551 nicht im Mittel 75mA und nur im Peak 200mA für Mikrosekunden, mit der entsprechenden Pufferplatine ginge es evtl. 😉 Oder CAN-Mikrocode auf TI MSPM0 ... so macht es eine Medizinfirma für deren CAN-Komponenten, werde mal nächste Woche nachfragen, der Bus dort hat 50mA Limitierung.

[alanz]

Also wenn Du mich fragst: Lieber kürzer und zielgerichtet handgeschrieben, als "passabel" mit ausufernden Details (wie z.B. git als Requirement) die Blick aufs wesentliche verwässern...

Da scheiden sich die Geister . Für meinen Geschmack ist die Readme noch viel zu kurz. Für mich gehört das alles rein, was ich wissen muss, um an dem Projekt mit zu entwickeln.

Wenn ich das richtig sehe, dann verwendest Du die vergleichbare Hardware für die CAN-Anbindung wie Sisamiwe (der eine andere Bibliothek verwendet). Du nutzt mit eine leicht angepasste Version einer CAN-Bibliothek https://github.com/Blizzard26/Seeed_Arduino_CAN .

Die Original-Bibliothek hat bei jedem Aufruf von checkError einen Reset der Error-Flags gemacht auch wenn gar kein Error-Flag gesetzt war. Der Reset dauert aber recht lange und hat zu Paket-Verlusten geführt. Daher hatte ich das angepasst. Wollte da mal noch einen PullRequest gegen die Original-Bibliothek machen, bin aber nie dazu gekommen.

Nutzung von loop(configured) statt loop()

Passe ich an.

Wozu readParams ?

Die Parameter werden danach als Teil der Info ausgegeben und an das KNX2Hoval Modul weitergereicht. Ich habe solche Dinge gerne zentral und nicht überall über den Code verstreut.

Zur Ermittlung von Laufzeiten kannst Du auf die Runtime-Statistic-Funktion zurückgreifen, die in OpenKNX-Common enthalten ist.

Das ist noch ein überbleibsel von einer Zeit wo ich das ganze Hauptsächlich ohne OpenKNX getestet habe. Das kann raus. (Ist aktuell aber auch nicht aktiv)

Du schreibst direkt aufs Diagnose-KO? (das wäre unerwartet)

Ich vermute du meist das hier: https://github.com/Blizzard26/OAM-KN...dule.cpp#L154? Das hatte ich mir so vom LogicModul abgeschaut. Was wäre hier die richtige Lösung?

Fortsetzung (und bitte nicht böse sein, dass ich da nun einfach erst mal eine weitere Liste über den Zaun werfe):

Definitiv nicht. Ich bin für jedes konstruktive Feedback dankbar. Egal in welcher Form.

Du hast noch ältere Modul-Releases im Einsatz

Werde ich aktualisieren. Als ich sie eingebunden hatte waren das die aktuellen Versionen.

Zu den git submodules: Hatten wie früher mal evaluiert und uns bewusst dagegen entschieden. Damit ist ggf. auch ein Update auf die jeweils aktuellen v1 Releases einfach möglich

Das Probleme verstehe ich nicht. In den Submodule-Order wechsel

git checkout v1

oder welche Stand auch immer und dann einfach im darüberliegenden Ordner ein

git add lib\

und den Stand commiten. Wir verwenden das auf der Arbeit täglich mit vielen verschiedenen Ständen, Branches etc. und hatten noch nie irgendwelche Probleme / Einschränkungen. Am aktuellen Ansatz von OpenKNX gefällt mir nicht, das alle ausgecheckten Projekt quasi den selben Stand der Lib verwenden. Wenn man da zwischen Projekten mit unterschiedlichem Stand welchselt hat man doch Chaos.

firmwareRevision sollte über die XML-Definition erfolgen. Das ist wesentlich bequemer und weniger Fehleranfällig. Dazu ggf. mal in aktuelle Releases schauen z.B. StateEngine (da ist es drin)

👍

Wozu die Serial-Ausgabe in setup()? Für Ausgaben solltest die entsprechenden Funktionen aus Common verwendet werden. Die bilden auch verschiedene Log-Level an und können direkt ein Modul-Präfix ausgeben. Teilweise nutzt Du die auch schon.

Überbleibseln von einem Vor-OpenKNX Stand.

Wozu setup1/loop1? Wenn ich nichts übersehen habe, dann nutzt Du im Modul den zweiten Core nicht. Könnte aber für CAN-Bus-Kommunikation sinnvoll sein.

Ich hatte mal mit dem zweiten Core experimentiert. Das aber nie weitergetrieben, da es bisher nicht nötig wäre. Wenn man noch mehr Module hinzufügt wird es vermutlich irgendwann notwendig. Die Nachrichten auf dem Hoval-Bus kommen (insbesondere bei Multi-Part-Messages) teilweise sehr schnell und ich hatte auch so schon vereinzelt Package Drops bei langen Multi-Part Messages. Aber da ich die bisher sowieso nirgends verwende war das bisher nicht kritisch.

Warum die abweichende Struktur der platformio.ini ?

Ehrliche Antwort: Weiß ich nicht mehr . ISW - Isch so worra.

Nutzung includes: Ziemlich viele und auch solche eigentlich nicht nötig sein sollten. Zum Ausschluss von Mehrfach-Includes steht #pragma once zur Verfügung

pragma once unterstützt nicht jeder Compiler - spielt hier aber keine Rolle. Könnte man sicher anpassen.
Mit den Include kämpfe ich immer. Da fehlt mir die Erfahrung mit C++.

Die Nutzung vom Kürzel LOG/log ist unglücklich, da Verwechslungen mit Logikmodul möglich.

Wenn du damit das Kürzel für das LogicModul meinst, das hatte ich mir so irgendwo bei einem anderen Projekt abgeschaut. Frag mich aber bitte nicht mehr bei welchem. Was wäre den hier sinnvoll?

Jedes Modul benötigt ein eindeutiges Kürzel, das ist auch Voraussetzung für die Funktion vom Config-Transfer. Du hast hier nun HOVAL angegeben. Üblich sind hier Kürzel von 3 Buchstaben, in Einzelfällen haben wir auch mal 2 oder 4. Würde hier aber ungern von abweichen.

Du meinst das Kürzel aus der KNX2HovalGateway.conf.xml? Passe ich gerne an.

[alanz]

ich hab mir mal ein paar CAN Transceiver angeschaut und leider ist die Stromaufnahme der CAN Transceiver nicht ganz ohne. Bis zu 200mA @5V werden hier veranschlagt (nicht in jedem Zustand, aber max) - das ist deutlich zu viel für Bus-Powered..

Aus diesem Grund beziehe ich den Strom für den Transceiver von den 12V vom Hoval-Bus. Die sind zum Betrieb mehrerer Displays und Transceiver. Daher sollte dort genug Spielraum sein.