Fingerprint an SEN-UP1-8xTH

[henfri]

Hallo,

ich habe die OpenKNX Firmware für den Fingerprint an die SEN-UP1-8xTH Hardware angepasst.
Den Code findet ihr hier:
https://github.com/henfri/OAM-FingerprintUP1
In hardware/Pinout.jpg findet sich die nötige Verschaltung. (@ing-dom : Das ist dein Bild, bitte lass mich wissen, wenn ich lieber ein eigenes machen soll).

Ein erster Test war erfolgreich.
abtools Sollte ich jetzt einen PR erstellen?

Danke nochmal Ing-Dom, mumpf , traxanos bei den ersten OpenKNX Gehversuchen und abtools für die originale Firmware.

Gruß,
Hendrik

[Ing-Dom]

(@ing-dom : Das ist dein Bild, bitte lass mich wissen, wenn ich lieber ein eigenes machen soll).

Das ist völlig ok
Idealerweise beschreibst du aber auch die anderen Pins (SWA, BI)

Danke an dich, dass du zu OpenKNX beiträgst. Das ist der OpenSource Gedanke.

Ich werde das heute Abend mal testen - FP-Scanner hab ich da und UP1 sowieso


Das hier sollte man aber denke ich in dem Zuge überarbeiten
https://github.com/henfri/OAM-Finger...nt.cpp#L19-L27
die fixen Pins sollte man durch passende defines OPENKNX_FP_SCANNER_RX_PIN etc... ersetzen.

Dann steht auch dem Ziel dass man den FP als OFM hat ein Stein weniger im Weg.

[abtools]

Hallo Hendrik,

Ein erster Test war erfolgreich.
abtools Sollte ich jetzt einen PR erstellen?

Danke nochmal Ing-Dom, mumpf , traxanos bei den ersten OpenKNX Gehversuchen und abtools für die originale Firmware.

Gerne, ich plane die nächsten 2 Wochen oder so ohnehin mal wieder ein Update der Fingerprint-Firmware zu veröffentlichen; dann kann ich das auch noch mit rein nehmen.

Das hier sollte man aber denke ich in dem Zuge überarbeiten
https://github.com/henfri/OAM-Finger...nt.cpp#L19-L27
die fixen Pins sollte man durch passende defines OPENKNX_FP_SCANNER_RX_PIN etc... ersetzen.

Macht Sinn.
Lass das aber gerne erst einmal wie es ist, Hendrik, ich räume das dann im Zuge des Merges deines PRs auf.

Viele Grüße
Andreas

[henfri]

Top, danke!

[Sisamiwe]

In hardware/Pinout.jpg findet sich die nötige Verschaltung.

Super Sache.

Wie sieht es mir den Binäreingang bzw. Eingängen aus? Werden die auch unterstützt?

[henfri]

Nee, noch nicht. Müsste aber Recht einfach sein.

[henfri]

Hallo,

Korrektur:
Könnte zufällig gehen

    #define OPENKNX_BI_GPIO_PINS 28, 18, 29, 19
    #define OPENKNX_BI_GPIO_COUNT 4​

Der Relais-Kanal funktioniert auch, ggf. müssen die Pins noch angepasst werden:

    #define OPENKNX_SWA_CHANNEL_COUNT 1
    #define OPENKNX_SWA_SET_PINS 14
    #define OPENKNX_SWA_RESET_PINS 15
    #define OPENKNX_SWA_SET_ACTIVE_ON LOW
    #define OPENKNX_SWA_RESET_ACTIVE_ON LOW
    #define OPENKNX_SWA_BISTABLE_IMPULSE_LENGTH 50​

Das muss ein bistabiles -Relais sein auf Pin 14&15

So sind die GPIO in SEN-UP-8xTH definiert:

[B]#define THPCHANNEL_A_SCL 29
#define THPCHANNEL_A_SDA 28[/B]
#define THPCHANNEL_B_SCL 27
#define THPCHANNEL_B_SDA 26
#define THPCHANNEL_C_SCL 25
#define THPCHANNEL_C_SDA 24
#define THPCHANNEL_D_SCL 23
#define THPCHANNEL_D_SDA 22
#define THPCHANNEL_E_SCL 21
#define THPCHANNEL_E_SDA 20
[B]#define THPCHANNEL_F_SCL 19
#define THPCHANNEL_F_SDA 18[/B]
#define THPCHANNEL_G_SCL 17
#define THPCHANNEL_G_SDA 16
[B]#define THPCHANNEL_H_SCL 15
#define THPCHANNEL_H_SDA 14[/B]​

Die GPIOs müssen also an Channel A und F (je zwei möglich zw. SCL/SCA und GND). Das Relais an Channel H.

Man könnte das ohne Weiteres noch erweitern, z.B. auf vier Relais und 6 Inputs.

Ich sehe gerad, dass der GPIO zweimal verwendet wird. Das muss ich noch anpassen abtools

    #define SCANNER_TOUCH_PIN 19
    #define OPENKNX_BI_GPIO_PINS 28, 18, 29, 19

Gruß,
Hendrik

[mumpf]

Hi Hendrik,

mit gefällt nicht, in welche Richtung das hier geht. Dein Engagement in Ehren, aber wenn Du was bei uns modifizierst und in den Standard wieder aufgenommen haben willst (über PR), dann würde ich zumindest erwarten, dass die Änderung entsprechend getestet worden ist - entweder von Dir oder von anderen Leuten, mit denen Du zusammenarbeitest.

Das Aufwändige bei unseren Entwicklungen ist ja nicht die Komposition der Module, sondern das sicherstellen der Qualität - sprich tests der möglichen Kombinationen mit entsprechender Hardware. Und wenn Du Relais für Dich verfügbar machen willst, sag ich nichts dagegen, das kannst, darfst und sollst Du sogar. Aber wenn Du es anderen zur Verfügung stellen willst, muss Du auch die Antwort haben, welche Relais, wie sie beschaltet werden und welche Probleme es bei Dir beim Testen gab - was man also vermeiden sollte. Idealerweise auch einen kleinen Schaltplan für die Relaisschaltung.

Sorry, das musste ich mal sagen, weil ein paar #defines machen können wir auch...

Verstehe mich nicht falsch, ich finde es gut, wenn Du die Sachen erweiterst und ich habe Dich hier ja auch unterstützt. Aber die letzten beiden Beiträge haben mir nicht gefallen, weil sie sich für mich nach ungetesteten Änderungen anhören, die noch in den PR an Andreas sollen. Da ist aber mein Qualitätsanspruch höher.

Gruß, Waldemar

[henfri]

Hallo Waldemar,

ich hoffe, ich habe das nicht in den falschen Hals bekommen...
Ich schrieb oben, dass "ein erster Test erfolgreich war".

Als die Frage nach den Relais kam, schrieb ich zunächst, dass es nicht geht, dann aber, dass es "gehen könnte". Zudem ist mir aber aufgefallen, dass der GPIO19 zweimal genutzt wird. Das ist ein Fehler. Das kann passieren. Aber nochmal: ein erster Test inkl. Anlernen und mehrmaligem Öffnen war erfolgreich.

Relais und Inputs sind nicht getestet.
Ich weiß also nicht so ganz, was ich falsch gemacht habe... Ich war doch transparent.

Ich werde die Kombination zukünftig produktiv nutzen. Aber ohne Input und ohne Relais.
Ich habe hier auch kein bistabiles Relais zum testen. Wie gehen wir damit um? Raus damit aus der Firmware, oder Hinweis auf ungetestet?
Die Inputs kann ich natürlich testen.

Gruß,
Hendrik

[mumpf]

Ich werde die Kombination zukünftig produktiv nutzen. Aber ohne Input und ohne Relais.

So hatte ich Dich ursprünglich verstanden. Und daraus einen PR machen, ist prima.

Und Andreas wird den PR annehmen (hat er ja schon gesagt) und dann kommt in die Doku, dass der FP jetzt auch mit dem SEN-UP1-8xTH läuft und die Applikation Binäreingänge und Schlataktor anbietet, die aber mit dieser Hardware nicht implementiert sind. Wir haben - bedingt durch die Modularisierung - in finalen Applikationen, die auf unterschiedlicher Hardware laufen, immer wieder Module oder Modulteile, die nicht laufen können (da arbeiten wir an einem Konzept, diese zukünftig auch ausblendbar zu machen).

Relais und Inputs sind nicht getestet.
Ich weiß also nicht so ganz, was ich falsch gemacht habe... Ich war doch transparent.

Wenn man offen diskutiert, ist eine kritische Anmerkung ja nicht gleich ein Vorwurf, dass alles falsch ist. Ich habe ja nur geschrieben, es gefällt mir nicht, in welche Richtung das läuft.
Aus meiner Sicht Dein letzter Beitrag impliziert, dass Du die Sachen mit Relais und Inputs auch in den PR mitmachst. Und meiner Meinug gehört das da nur rein, wenn es getestet ist.

Kurz zusammengefasst: Lokale Änderungen, Anpassungen, Tipps hier im Thread, was noch gehen könnte - alles prima. PR-Inhalte, die ins Release sollen aber nur mit getesteten Sachen.

Da der FP aber von Andreas verwaltet wird, kann er das naütrlich auch anders sehen. Ist eben meine Meinung.

Gruß, Waldemar

[henfri]

Hallo Waldemar,

ich hab's noch immer nicht verstanden.

Aus meiner Sicht Dein letzter Beitrag impliziert, dass Du die Sachen mit Relais und Inputs auch in den PR mitmachst.

Naja, es ist halt so, dass die FP Applikation Inputs und Outputs enthält. Ich muss also die Defines mit irgendwas belegen (ohne es getestet zu haben wird sonst der Code nicht kompilieren oder es werden Defaults versendet).
In dem Sinne sind die Relais und Inputs schon im PR.

Was sind jetzt die Möglichkeiten?
1) Relais und Inputs rauspatchen, so das in der Applikation nicht mehr sichtbar
2) Drin lassen, I/Os testen und Relais als ungetestet dokumentieren. Das sorgt für eine niederschwellige Möglichkeit, das zu testen

Nochmal: Ich weiß nicht, was ich bei meinem PR hätte anders machen können, außer gleich die Dokumentation auch anzupassen. Ich bin da aber gerne für Feedback offen.

Gruß,
Hendrik

[abtools]

Hallo Hendrik,

Naja, es ist halt so, dass die FP Applikation Inputs und Outputs enthält. Ich muss also die Defines mit irgendwas belegen (ohne es getestet zu haben wird sonst der Code nicht kompilieren oder es werden Defaults versendet).

Ist das so?
In den Defines gibt's ja einen "Count" für beides.
Was passiert denn, wenn du den einfach auf "0" setzt und die PIN-Definitionen weg lässt?

Was Waldemar sicherlich meint, ist, dass alles, was in ein "offizielles" Release soll (und dazu führt ja dein PR), auch getestet sein muss.
Wenn du also die Binäreingänge sowie das Relais nicht testen kannst, sollten diese auch nicht im PR sein. Ggf. geht das mit einem "Count = 0", hab' ich aber selbst auch nicht getestet. Müsstest du also ausprobieren und sicherstellen, dass dann noch alles korrekt funktioniert. Falls es das aktuell nicht tut, kann der Code sicherlich so geändert werden, dass er auch mit "0" Binäreingängen und Relais klarkommt.

Den PR übrigens bitte gegen "devel", nicht "main".

Viele Grüße
Andreas

[henfri]

Hallo Hendrik,



Ist das so?
In den Defines gibt's ja einen "Count" für beides.
Was passiert denn, wenn du den einfach auf "0" setzt und die PIN-Definitionen weg lässt?

Also beim Switch funktioniert (kompiliert) dies:

    #define OPENKNX_SWA_CHANNEL_COUNT 0
    #define OPENKNX_SWA_SET_PINS
    #define OPENKNX_SWA_RESET_PINS
    #define OPENKNX_SWA_SET_ACTIVE_ON LOW
    #define OPENKNX_SWA_RESET_ACTIVE_ON LOW
    #define OPENKNX_SWA_BISTABLE_IMPULSE_LENGTH 50​

Beim GPIO gibt es diesen Fehler

src\main.cpp: In function 'void setup()':
src\main.cpp:16:26: error: 'openknxGpioBinaryInputModule' was not declared in this scope
   16 |     openknx.addModule(5, openknxGpioBinaryInputModule);
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~​

Der lässt sich sicher auch mit einem Define abfangen, aber:

Wir haben - bedingt durch die Modularisierung - in finalen Applikationen, die auf unterschiedlicher Hardware laufen, immer wieder Module oder Modulteile, die nicht laufen können (da arbeiten wir an einem Konzept, diese zukünftig auch ausblendbar zu machen).

Solange es dieses Konzept nicht gibt, wird die Applikation doch ohnehin weiter den (einen) Switch und die (vier) GPIO anzeigen, oder?
Was erreichen wir also, wenn ich die Defines hier weglasse?

Was Waldemar sicherlich meint, ist, dass alles, was in ein "offizielles" Release soll (und dazu führt ja dein PR), auch getestet sein muss.
Wenn du also die Binäreingänge sowie das Relais nicht testen kannst, sollten diese auch nicht im PR sein. Ggf. geht das mit einem "Count = 0", hab' ich aber selbst auch nicht getestet. Müsstest du also ausprobieren und sicherstellen, dass dann noch alles korrekt funktioniert. Falls es das aktuell nicht tut, kann der Code sicherlich so geändert werden, dass er auch mit "0" Binäreingängen und Relais klarkommt.

Das ist die Frage, was du mit "sollten diese auch nicht im PR sein" meinst.
Nicht in der Firmware ist leicht machbar.
Nicht in der knxprod: Ich fürchte da fehlt o.g. Konzept.

Das gleiche Problem besteht übrigens für die Touch-Buttons und LED.
Die mit Defines rauszunehmen keht natürlich, aber das hilft nicht für den User, der es weiter in der Applikation sieht.

Gruß,
Hendrik

[traxanos]

Die knxprod muss immer alles beinhaltet. Die ETS ist nicht so Modular wie unsere Software. Was mumpf meint ist, dass man Module optisch ausblenden kann. Diese sind aber weiter in der ETS vorhanden. Es ändert sich also Funktional nichts.

Wenn du eine Firmware ohne GPIO Bauen möchtest, muss du mittels define das laden des Modules auch verhindern bzw erst aktivieren. Ein Count 0 wird das Modul nicht deaktivieren, es wird immer ein Channel als Min. erwartet. Sonst kann man das Modul auch rauslassen. 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.

[Ing-Dom]

die GPIOs sind ja nicht das Problem. Die kriegt man ja sinnvoll zum Laufen.
Der SA Kanal ist das "Problem".
Wir haben in dem Konzept nicht bedacht oder nicht zu Ende bedacht, dass man in einem OAM Targets hat, die ein Modul nicht benutzen...