Funktionen von OpenKNX Firmwares kombinieren

[henfri]

Hallo,

ich möchte demnächst die Firmware vom Openknx Fingerprint anpassen, damit es auf dem UP1 von Ing-Dom läuft.
Jetzt sind aber gerade noch Anforderungen hinzu gekommen:
1) Binäreingänge - hat es schon, da muss ich sicher nur die GPIOs anpassen
2) Schaltausgänge - hat es nur einen, ich denke, das bekomme ich leicht erweitert
3) Temperatursensoren - das wirkt aufwändiger. Aber da OpenKNX ja sehr modular aufgebaut ist, habe ich die Hoffnung, dass man "nur" aus der Sensormodul-Firmware das entsprechende Modul übernehmen muss

Wie aufwändig ist das?

Gruß,
Hendrik

[mumpf]

Hallo Hendrik,

modularer Aufbau ist einer der Vorteile, die wir haben - allerdings bedeutet das Stand heute nicht, dass man einfach ein paar Module zusammenkopiert und dann läuft das. Da spielen solche Aspekte wie Timing und stellenweise rudimentäre Hardware-Abstraktions-Layer auch noch eine Rolle. Und selbst wenn Features kombinierbar sind, ist es auch die Frage, ob sie kombiniert werden sollten. Aber das musst Du dann entscheiden.

Die FP-Firmware beinhaltet bereits das Binäreingangsmodul und das Schaltaktormodul. Dieses kann nur GPIO schalten und sicherlich auf mehr Kanäle erweitert werden.
Bei Temperatursensoren (mehrzahl) wird es aber nicht funktionieren. Derzeit ist das Sensormodul ein 1-Kanal-Modul. Damit wirst Du also nur einen Temperatursensor abfragen können. Mehrkanalige Umsetzung ist aufwändig (multiplexing von Eingängen), dazu konnte ich mich bisher nicht aufraffen.
Und da es mein ältestes Modul ist, ist seine Anbindung komplexer als bei den anderen (neueren) Modulen. Aber da kann ich Dich unterstützen, allerdings müssten wir dann ein paar Online-Sessions machen, das ist zu aufwändig, alles hier zu schreiben.
Zum Aufwand:
Du musst eben bei der Planung zusehen, dass Dir die GPIOs nicht ausgehen, dass die passenden Pins für I²C und UART zum FP und UART zur BCU frei sind und dass die Spannungen / Ströme passen und nichts zusammebricht, falls Du z.B. ein Relais ansteuern willst.
Du musst eine neue Applikation für die ETS machen (OAM-xxx) und da die Module einbinden, eine passende Hardware-Definition erzeugen (BOARD_xxx) mit den Pin-Belegungen und dann kann man schon mal probieren, wie weit das kommt.
Dein DEVEL-Board solte einen Debug-Anschluß haben und Du solltest einen Debugger haben, um auch Probleme untersuchen zu können, die außerhalb von Logging auftreten können.
Und dann wie immer, wenn man mit Hardware rumspielt, auch hier "Debuggen" können, mit Oszi, Labornetzteil und Messgeräten ausgerüstet sein. Das ist aber nicht meine Kernkompetenz, deswegen freue ich mich ja immer, dass wir Leute im OpenKNX-Team haben, die Hardware gerne machen und das auch können .

Aus meiner (Laien)-Sicht würde ich sagen, UP1 + FP + ein I²C-Sensor ist kein Problem, Schaltaktor wird Probleme machen, wenn das Ganze Busversorgt bleiben soll.

Gruß, Waldemar

[Ing-Dom]

an sich ist das nicht so irre komplex.
Am Ende musst du nur ein Sensormodul OFM in deine private Kopie des OAM-Fingerprint einbauen.

hierbei hast du die Wahl zweischen OFM-THPSensorModule (was auch der SEN-UP1 nutzt) oder das OFM-Sensormodule, welches mehr Sensoren, aber nur einen Sensor jeder Art. Das THP ist wahrscheinlich etwas leichter zu integrieren (weil weniger Abhängigkeiten).

mal so eine grobe Roadmap:

- OAM-Fingerprint in dein privates github forken
- dependencies etc.. laden
- den aktuellen stand (branch) erfolgreich duchbauen
- das gewünschte HW-Target hinzufügen und auf der HW testen (hardware.h, plattformio.ini)

erst dann solltest du dir Gedanken über eine Adaption der FW machen.

OFM-xyz dahin klonen wo auch die anderen liegen
symlink ins lib verzeichnis erstellen
in der main einbinden (header sowie addModule)
das schwierigste ist dann die Anpassung der xml - Offsets etc... auf jeden Fall eine neue ID vergeben sonst kommt es zu Kollisionen.

Fang mal an und wenn du Probleme bekommst melde dich wieder.

edit: Waldemars Antwort hab ich erst nach meinem Post gesehen. war praktisch zeitgleich

[mumpf]

Ing-Dom: Ich war mir nicht sicher, ob Dein THPSensorModule wirklich nur die GPIO anspricht, die für die Sensorauswertung im der ETS definiert sind und die anderen GPIO "in Ruhe" lässt. Aber wenn das so ist, dann solltest Du henfri unbeidngt den THPSensorModule nehmen, da der prinzipiell mehrere Temperatursensoren abfragen kann.

Gruß, Waldemar

[henfri]

Hallo,

vielen Dank für eure Antworten.
Puh, es würd mich ja schon reizen. Ich fang erstmal mit dem Fingerprint an. Und je nach dem, wie leicht ich mich da tue, wage ich mich zunächst an den zweiten Schaltaktor-Kanal und dann ggf. noch an die Temperatur.

Danke euch. Jetzt muss erstmal die Hardware ankommen und ich muss Zeit finden.

Viele Grüße,
Hendrik

[Ing-Dom]

Ich war mir nicht sicher, ob Dein THPSensorModule wirklich nur die GPIO anspricht, die für die Sensorauswertung im der ETS definiert sind und die anderen GPIO "in Ruhe" lässt

was genau meinst du damit?
Dass GPIOs parallel vom THP-Sensormodul als auch vom FP/SA angesprochen werden?
Ich hätte sowieso die Pins exklusiv zugeordnet - also statt 8 THP-Channels (mit je zwei GPIOs) zB
1 Fingerprint (4 GPIOs)
3 Schaltaktor (6 GPIOs - bistabile Relais !)
3 THP-Channels

THP ist halt Dualcore - da muss man ggf aufpassen falls andere Module auch Dualcore machen - FP ??

[henfri]

Hallo,

mal so eine grobe Roadmap:

- OAM-Fingerprint in dein privates github forken
- dependencies etc.. laden
- den aktuellen stand (branch) erfolgreich duchbauen
- das gewünschte HW-Target hinzufügen und auf der HW testen (hardware.h, plattformio.ini)

Am dritten Schritt scheitere ich.

Platformio meckert über einen Fehler in der platformio.ini.
Leider bleibt die Meldung so unkonkret.
Jetzt wollte ich am terminal pio run oder platformio run ausführen -in der Hoffnung, dass es eine Fehlermeldung gibt. Das Kommando wird aber nicht gefunden.

Was mir auch auffällt ist, dass der Ordner OAM-FingerprintUP1 zweimal angezeigt wird:
image.png
Gibt es aber natürlich nur zweimal:

├───OAM-FingerprintUP1
│   ├───doc
│   ├───hardware
│   ├───include
│   ├───lib
│   ├───lib-crc16
│   ├───restore
│   ├───scripts
│   ├───src
│   │   └───Baggages
│   │       └───Help_de
│   └───test
├───OFM-Logicmodule
├───OFM-SwitchActuator
├───OFM-VirtualButton
├───OGM-Common
​

Ich hab auch die platformio.ini einmal so angepasst:

[platformio]
libdeps_dir = %userprofile%/.platformio/libdeps
extra_configs =
  lib/OGM-Common/platformio.base.ini
  lib/OGM-Common/platformio.rp2040.ini
  platformio.custom.ini​

Das hilft auch nicht.

Seht ihr meinen Fehler?

Gruß,
Hendrik

[MarcoLanghans]

henfri wie ist den die Meldung genau? Und was steht alles in deiner .custom?

[henfri]

Hallo,

hier ein Screenshot der Fehlermeldung:
Code_YkWBaHWgXj.png

Die .custom ist diese:
https://github.com/OpenKNX/OAM-Finge...mio.custom.ini

Gruß,
Hendrik

[mumpf]

Hi Hendrik,

was mir so auffällt: Wenn Du OAM-Fingerprint geforked hast in ein eigenes Repo, dann wird ja nichts umbenannt. Also ist Dein FingerprintUP1 ja irgendwie von Dir nochmal umbenannt. Ich wüsste jetzt selber nicht, was alles im Projekt von dem eigentlichen Namen abhängt. Ich will damit sagen, dass ein Umbenennen nicht unbedingt problemlos ist. Ich sag nicht, dass Du nicht umbenennen sollst, vor allem, falls Du das mal veröffentlichen willst, aber ich würde es nicht gleich zu Anfang machen.

Und dann arbeitest Du mit UNC-Pfaden, also ist Dein Verzeichnis auf irgendeinem Server. Abgesehen davon, dass damit das Compilieren potentiell langsam ist, hab ich damit keine Erfahrungen, ich weiß nicht, ob das nicht für Probleme sorgt. Auch hier würde ich versuchen, erstmal was erfolgreich auf einer lokalen Verzeichnisstruktur zu machen und dann erst versuchen, ob es auch anders geht.

Die von Dir verlinkte PIO.ini ist ja unsere, die funktioniert.

Ich würde nochmal starten ohne Umbenennung.

Gruß, Waldemar

[traxanos]

Existieren die symlinks unter lib?

[henfri]

Nein, das sind Text Dateien mit einem relativen Pfad.
Ich dachte, das löst VSCode auf...
Das ist natürlich dann eine naheliegende Ursache.

[traxanos]

ne du musst symlinks aktivieren und die symlinks müssen auch auf ein korrektes ziel zeigen.

[mumpf]

Du musst nach dem Clonen vom OAM-Fingerprint unser

restore/Restore-Dependencies-Branch.ps1

verwenden. Sollte aber auch so in der Anleitung (wiki, Development Setup) stehen.

Gruß, Waldemar

[Ing-Dom]

hier
https://github.com/OpenKNX/OpenKNX/w...for-Developers
und insbesondere hier
https://github.com/OpenKNX/OpenKNX/w...ct-from-Github