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.
Man kann aber sicher das ifdef in der main so gestalten, dass ein COUNT 0 das laden verhindert. Dann sind aber die anderen defines überflüssig.
genau.
wir sollten das irgendwie standardisieren, damit OFMs sich entweder "automatisch" deaktivieren "zB ein "#ifdef OPENKNX_SWA_CHANNEL_COUNT" um alles oder ein explizites OPENKNX_SWA_ENABLE oder OPENKNX_SWA_DISABLE.. teilweise haben wir ja schon auch das DISBALE
ja weil nicht jedes modul ein COUNT nutzt und ggf sogar später anders implementiert werden. und ich bin gegen enable. normal bau ich was ein weil ich es drinne haben möchte. diese ich bau alles in eine firmware geschichte sind für mich eher die ausnahmen und sollten auch gesondert behandelt werden. wenn man also das kompilieren verhindern möchte eher ein OPENKNX_SWA_DISABLE
Was bringt es, wenn wir jetzt mit defines etwas rausnehmen, es für den User aber immernoch sichtbar ist. Da haben wir doch nix gewonnen.
Das geht aber nicht anders und wird auch jetzt schon gemacht. Hab Verständnis dafür, dass sich die Entwickler rund um OpenKNX regelmäßig treffen und solche Sachen besprechen. Dazu gehört auch der Plan, dass wir Funktionen nur optisch ausblenden. Sonst müssen wir wie Hardwarehersteller einen festen Funktionsumfang an die Hardware bundeln und für jede Hardware auch eine eigene knxprod bereitstellen. Aber das wollen wir nicht.
Was also ins OAM vom Fingerprint landet und wie, ist erstmal die Sache von abtools idr in Rücksprache mit den anderen OpenKNX Entwicklern.
Hier ging es ja erstmal darum, dass du das OAM-Fingerprint auf dem UP1 laufen lassen möchtest. Dafür ein PR zu machen ist erstmal vollkommen in Ordnung. Über die Funktionen die noch rein wandern sollen wäre denke ich erstmal mit Andres zu besprechen.
Wenn du dir was individuelles bauen möchtest kannst du das natürlich auch machen. Das bedeutet aber auch das du dir ein eigenes OAM mit allen gewünschten Modulen bauen musst inkl einer eigenen knxprod mit eigener Id.
Solltest du gerne generell an der Entwicklung von OpenKNX mitwirken wollen, wäre es interessant dass du zu uns dazu zu stößt und dich dann erstmal in die Konzepte etc mit uns zusammen einarbeitest. Ich denke dir fehlt aktuell noch viel zu viel Hintergrundwissen.
Das geht aber nicht anders und wird auch jetzt schon gemacht. Hab Verständnis dafür, dass sich die Entwickler rund um OpenKNX regelmäßig treffen und solche Sachen besprechen. Dazu gehört auch der Plan, dass wir Funktionen nur optisch ausblenden. Sonst müssen wir wie Hardwarehersteller einen festen Funktionsumfang an die Hardware bundeln und für jede Hardware auch eine eigene knxprod bereitstellen. Aber das wollen wir nicht.
Soll nix in der ETS sichtbar sein, was nicht getestet ist?
Soll nix im Code sein, was nicht getestet ist?
Also 2?
Solltest du gerne generell an der Entwicklung von OpenKNX mitwirken wollen, wäre es interessant dass du zu uns dazu zu stößt und dich dann erstmal in die Konzepte etc mit uns zusammen einarbeitest. Ich denke dir fehlt aktuell noch viel zu viel Hintergrundwissen.
Das ist evident.
Ich verzweifle hier gerade ein bisschen, weil wir vollkommen aneinander vorbei reden.
1) Der FP läuft auf der Hardware und ist getestet
2) Binäreingänge, LED kann ich testen. Touch ggf. auch
3) Relais nicht
SWA/Relais kann im Define auf Null gesetzt werden.
Was konkret ist denn nun das Problem? Ich verstehe es wirklich nicht.
Selbst wenn ich die GPIO nicht teste: Was ist Unterschied zwischen
a) mit defines deaktivieren
b) GPIOs zuweisen
und in beiden Fällen zu dokumentieren, dass GPIOs nicht unterstützt sind.
Nochmal: Mir ist nicht klar, was jetzt die Zielsetzung ist.
Sobald mir das jemand sagt, kann ich versuchen, es umzusetzen.
Meine Aussage war allgemein bezogen aufgrund einiger deiner Probleme/Aussage u.a. mit dem Laden etc.
Aber ich verstehe auch nicht was deine Zielsetzung ist. Wolltest du nur das oam für den up1 erweitern? Das hätte ich beim OAM owner gesehen. Vor allem weil sein OAM auch noch nicht in ofm aufgeilt wurde (meine ich) und da sicher noch paar andere todos offen sind.
oder willst du dir eine spezielle Version bauen. Wenn du nur den up1 einbauen willst sollte doch ein pr auch mur das enthalten. Wenn das oam noch zu hw spezifisch musst der owner ggf noch Vorbereitungen treffen. Auch das sehe ich aktuell beim owner.
warum? Weil wenn ich der owner wäre, würde ich das auch selber machen wollen. Anders sieht das aus wenn das jemand macht der die ganzen Konzepte kennt und versteht.
bitte nicht falsch verstehen, ich hab mit deinen source bzw Änderungen nicht angeschaut ist also eine allgemeine Meinung und nicht die Arbeit schlecht machen.
Aber ich verstehe auch nicht was deine Zielsetzung ist.
Ich nutze den FP an der SEN-UP1-8xTH Hardware.
Das habe ich soweit angepasst und einen ersten Test gemacht. In den nächsten Tagen/Wochen werde ich mehr Erfahrung damit machen.
Ich nutze nicht das Relais/Touch/LED/Binäreingänge. Einen Teil davon kann ich testen, nicht alles.
Jetzt kann ich das alles für mich behalten. Aber mein Ziel wäre, dass diese Anpassungen nicht jeder für sich machen muss.
Die Anpassungen sind auch vollkommen unschädlich (ein paar Defines).
Wenn das oam noch zu hw spezifisch musst der owner ggf noch Vorbereitungen treffen.
Ich würde nicht sagen, dass es zu hw-spezifisch ist. Man kann die optionale Hardware (Touch-Platine mit LED) sogar in der ETS aktivieren/deaktivieren.
Aber selbst wenn die Hardware nicht vorhanden ist, muss man die GPIO definieren (sei es auf der UP1 Hardware oder auf der originalen Platine). Sonst kompiliert es nicht.
Also definiert man einfach GPIO und gut.
Sorry, ich hab jetzt damit mehr losgetreten als ich wollte.
Ich wollte nur verhindern, dass es heißt, diese Hardware kann jetzt auch Schaltaktor und Binäreingänge in der FP-Firmware, obwohl das noch niemand getestet hat. Wir können das beenden, ich werde mit Andreas besprechen, welche Schritte noch im OAM-Fingerprint zu tun sind, die Firmware wird ja noch weiter entwickelt.
Aber der Satz von Dir zeigt den Unterschied zwischen "etwas für sich bauen" und "etwas ins Release aufnehmen":
Aber selbst wenn die Hardware nicht vorhanden ist, muss man die GPIO definieren (sei es auf der UP1 Hardware oder auf der originalen Platine). Sonst kompiliert es nicht.
Also definiert man einfach GPIO und gut.
Das ist für private Erweiterungen prima, mach ich selber manchmal so. Aber wenn ich es releasen möchte, würde ich
keine GPIO definieren, die nicht unterstützt werden, da man nie weiß, was die Firmware jetzt oder in Zukunft mit den Pins anstellt,
die Firmware so anpassen, dass sie ohne diese Definitionen entsprechend immer noch kompiliert und keine Pins anspricht.
Aber wie gesagt, ich werde das bei uns adressieren. Ich möchte Dich nicht demotivieren, hier mitzumachen. Und ich wollte Dir nicht "auf den Schlips treten". Falls das so war, dann bitte ich um Entschuldigung.
Was ich aber immer machen werde, ist offen zu kommunizieren, wenn ich denke, dass es in die falsche Richtung läuft. Dann kann man darüber diskutieren und zu einem Ergebnis kommen.
die Firmware so anpassen, dass sie ohne diese Definitionen entsprechend immer noch kompiliert und keine Pins anspricht.
Das ist in der originalen Firmware nicht so gemacht. Kann ich auch nachvollziehen, denn diese Hardware ist ja ein optionales Aufsteckmodul. Was machen wir da jetzt? Deswegen zwei Firmwares?
Vor allem weil sein OAM auch noch nicht in ofm aufgeilt wurde (meine ich) und da sicher noch paar andere todos offen sind.
oder willst du dir eine spezielle Version bauen. Wenn du nur den up1 einbauen willst sollte doch ein pr auch mur das enthalten. Wenn das oam noch zu hw spezifisch musst der owner ggf noch Vorbereitungen treffen. Auch das sehe ich aktuell beim owner.
Also hier muss ich jetzt mal widersprechen bzw etwas aanmerken.
Der PR geht ja immer noch zum Maintainer des Repo. Da liegt die Entscheidung ob ud wie etwas angenommen wird. Das wurde gemacht.
Mir ist der Weg dass jemand der etwas möchte einen PR macht 100x lieber als wenn Features "bestellt" werden. Auch wenn der PR am Ende nichts taugt, selber machen kann ich es dann immer noch !
Also ich finde, henfri hat diesbezüglich absolut keinen Fehler gemacht. PRs sind vollkommen normale und höfliche Anfragen ein bestimmtes Feature umzusetzen, und mit der Lösung gleich dazu.
Was ist denn nun in die falsche Richtung gelaufen?
Waldemar ging es wohl in allererster Linie darum, dass der Build einen Schaltaktorkanal enthält, dessen Funktion du weder durchdacht, noch getestet hast. So verstehe ich es. Und ich stimme insofern zu, dass es wenig Sinn macht hier GPIOs herauszuführen - man müsste dann Relais + Treiberschaltung extern haben.. das macht wenig Sinn und ist sehr fehleranfällig.
Man sollte es hier einfach weglassen. WIE ist die Frage. a) auf ungenutzte GPIOs legen oder b) die FW so anpassen dass bei passenden defines das Modul gar nicht inkludiert wird.
a) geht schneller, hat aber was von einem "hack".
b) da sollten wir uns grundsätzlich eine Vorzugs / Standardlösug überlegen.
wenn ich denke, dass es in die falsche Richtung läuft.
Zu dem Zeitpunkt, als ich meine erste Kritik hier angebracht habe, dachte ich, dass Du eine Erweiterung machst, die Du nicht getestet hast und diese in einen PR packen willst. Das finde ich nicht gut und das habe ich gesagt. Mehr nicht.
Ansonsten schließe ich mich der Erklärung Ing-Dom an.
Zu dem Thema ist aus meiner Sicht genug gesagt, ich habe meine Hilfe angeboten, Andreas hier zu unterstützen und bin zu dem Thema erstmal raus.
Man sollte es hier einfach weglassen. WIE ist die Frage. a) auf ungenutzte GPIOs legen oder b) die FW so anpassen dass bei passenden defines das Modul gar nicht inkludiert wird.
a) geht schneller, hat aber was von einem "hack".
b) da sollten wir uns grundsätzlich eine Vorzugs / Standardlösug überlegen
Ok, es ist ja kein Problem den SWA zu deaktivieren.
ich habe das jetzt getestet:
1) Binäreingänge - funktionieren
2) Touch-Eingänge - funktionieren, aber da ich keinen Pull-Down Widerstand hatte wurde das Signal mehrmals ausgelöst bis es stoppte
3) LED-Ausgänge - funktionieren (ich habe nur die Spannung gemessen)
4) Fingerprint
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.
Kommentar