Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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?
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.
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)
Ü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.
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..
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.
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.
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)
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
Code:
git checkout v1
oder welche Stand auch immer und dann einfach im darüberliegenden Ordner ein
Code:
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.
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.
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.
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.
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.
Du kannst auch jedes OAM-Projekt in einem eigenen übergeordneten Verzeichnis verwalten. Falls Du allerdings aktiv an einem Modul entwickelst und das in mehreren Applikationen nutzen willst dann ist das eben in einem Gemeinsamem Verzeichnis für alle OpenKNX-Projekte möglich.
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.
Zweiten Kern nur verwenden, wenn notwendig. Der Zugriff aus dem Stack kann nicht von mehreren Kernen erfolgen. Kritisches Timing bei komplexeren HW-Schnittstellen kann ein sinnvoller Grund sein das auf den zweiten Kern zu verlagern.
Das Diagnose-KO funktioniert wie ein Terminal: Du schickst ein Kommando hin und bekommst eine Antwort. Alle Kommandos müssen aus Kleinbuchstaben bestehen, die Antwort MUSS als erstes Zeichen einen Großbuchstaben haben.
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.
coko Den Grund verstehe ich nicht. Ich bin zwar für kurze Präfixe, aber ich meine mich zu erinnern, dass ich im OpenKNXproducer die ersten 10 Zeichen vom Präfix auswerte. Faktisch haben wir bisher 2-4 genutzt (auch aus Faulheit, damit man nicht so viel schreiben muss), aber HOVAL finde ich sehr passend, deswegen hätte ich gesagt, dass das ruhig bleiben kann, oder?
Zu git-submodules: Wir haben uns explizit gegen git submodules entschieden. Die sind gut dafür geeignet, Bibliotheken einzubinden, an den man aktuell nicht arbeitet. Die Realität in OpenKNX sieht aber so aus, dass man an 2, 3 oder 4 Modulen gleichzeitig arbeitet - ich hatte das letzte Mal 8 von 18 Modulen geändert. Und wenn Du in verschiedenen Projekten verschiedene Stände hast, an allen irgendwas geändert hast und die dann auch noch gegenseitig gemerged werden sollen, dann ist das die Hölle - vor allem, weil Merges von xml nicht so toll mit git klappen wie bei Sourcen.
Außerdem wollen wir immer mit den aktuellen Ständen arbeiten, ein Release soll immer die aktuellsten Modulversionen enthalten. Unser Referenzkonzept forciert das.
Das Diagnose-KO funktioniert wie ein Terminal: Du schickst ein Kommando hin und bekommst eine Antwort. Alle Kommandos müssen aus Kleinbuchstaben bestehen, die Antwort MUSS als erstes Zeichen einen Großbuchstaben haben.
Ok. Dann verwende ich hier ein separates KO für Fehlerzustände.
coko Den Grund verstehe ich nicht. Ich bin zwar für kurze Präfixe, aber ich meine mich zu erinnern, dass ich im OpenKNXproducer die ersten 10 Zeichen vom Präfix auswerte. Faktisch haben wir bisher 2-4 genutzt (auch aus Faulheit, damit man nicht so viel schreiben muss), aber HOVAL finde ich sehr passend, deswegen hätte ich gesagt, dass das ruhig bleiben kann, oder?
Am Ende ist mir egal ob HOVAL, HOV oder was anderes. Ich muss nur wissen was ich verwenden soll / darf
Zu git-submodules: Wir haben uns explizit gegen git submodules entschieden. Die sind gut dafür geeignet, Bibliotheken einzubinden, an den man aktuell nicht arbeitet. Die Realität in OpenKNX sieht aber so aus, dass man an 2, 3 oder 4 Modulen gleichzeitig arbeitet - ich hatte das letzte Mal 8 von 18 Modulen geändert. Und wenn Du in verschiedenen Projekten verschiedene Stände hast, an allen irgendwas geändert hast und die dann auch noch gegenseitig gemerged werden sollen, dann ist das die Hölle - vor allem, weil Merges von xml nicht so toll mit git klappen wie bei Sourcen.
Außerdem wollen wir immer mit den aktuellen Ständen arbeiten, ein Release soll immer die aktuellsten Modulversionen enthalten. Unser Referenzkonzept forciert das.
Bei mir hängt aktuell an der Hardware ein Raspberry PI den ich zum Debuggen und auch falschen verwende. Dort läuft dann auch ein PlatformIO um Änderungen direkt und einfach kopilieren und uploaden zu können. Powershell auf dem Raspi ist nicht so prikelnd. Da war die Lösung mit git submodule wesentlich einfacher.
Das Problem mit dem gleichzeitigen arbeiten kann ich nur bedingt verstehen. Ich würde da auf der Lib einen Branch anlegen innerhalb eines OAM die Änderungen machen, commiten, pushen und den branch in den anderen OAM einfach pullen. Ggf. viele kleine Commits (bin ich sowieso ein fan von) und am Ende aufräumen.
Aber das ist alles Geschmackssache. Ich habe am Ende auch kein Problem damit das entsprechend umzustellen. Für den Code macht es keinen Unterschied. Es war für mich so halt praktischer / einfacher / gewohnter und ich musste keine "klimzüge" mit anpassen der Entwicklungseinstellungen etc. unter windows machen, um die Softlinks zu ermöglichen.
coko Ein großteil deines Feedbacks habe ich auf diesem PR bereits umgesetzt. Ist aber noch ungetestet. Um die Diagnose-KO Thematik muss ich mich noch kümmern.
Was ich mich gerade noch Frage: Sollte ich das Kürzel von HOVAL auf HOV anpassen, ist dann noch ein Update möglich oder nicht?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
. ISW - Isch so worra.
Kommentar