Entwicklung eines Tastsensors

[willisurf]

Keine Ahnung, aber die Applikation ist sowieso sehr spartanisch.

[cad435]

Eine befreundete Innenarchitektin hat mir das so erklärt (bzw. so halb Vermutung, weil genau wissen wir's nicht):

Diese Schalter werden wahrscheinlich vor allem von Innenarchitekturbüros zum Einbau in Luxusgebäuden benutzt. Diese Büros bekommen wohl meistens einen Prozentualen Anteil am "Einkaufspreis" der Innenarchitektur die sie verkaufen.

Das heißt der Schalter muss vor allem zwei Dinge sein: Teuer (damit sich das für das Innenarchitekturbüro lohnt) und einfach (weil die jetzt auch ned unbedingt die großen KNX-Experten an der Hand haben)


Würde soweit ich mich in den letzten paar Wochen informiert habe beides zutreffen...

- cad435

[cad435]

Spontane Idee zur Benennung:Touch-Taster mit Optionalen Displays (Prefix TTD), wobei es toll wäre wenn wir damit dann beliebig viele Tastenpaare (habe das von Hardware-Seite nicht weiter geprüft) mit einem optionalen Display abbilden könnten. Das ist über Channels recht einfach möglich.

Mein Spontanvorschlag wäre "TVC" aka "TasterVierfachColor", aber ich finde TTD fast griffiger... Ich bastel das mal so rein.

Das mit den Channels und den Wiederholstrukturen ist noch so ne Sache, da hab ich mich noch nicht ran getraut
Muss erstmal laufen.

Hardwaretechnisch kann der CAP1188 insgesamt 8 Tasten. Ich brauche/möchte evtl. eine für eine Proximity-Detection, da muss ich aber mal gucken ob ich die "proximity" auch einfach intern ausrechnen kann.

Andere Idee wäre mit einem IR sensor durch den schmalen plexiglasstreifen in der Mitte raus zu schauen (der VL6180 kann das wohl zu einem gewissen Grad, muss man aber ausprobieren...)

• Paramerer-Type: Name sollte mit letztem Teil in der Id übereinstimmen, Du hast hier teilweise sogar schon Duplikate
• Bei Text-Parametern musst Du berücksichtigen, dass diese als Null-terminiert erwartet werden. Im Speicherlayout daher noch ein leeres Byte (befüllt mit 0x00) dainter freilassen, ansonsten müsstestDu in der Firmware eine besondere Behandlung für das Fehlen bei Maximallänge vorsehen.

Das gibt absolut Sinn, hab ich so eingebaut, Danke!

• %AID%_P-%TT%00009 und %AID%_P-%TT%00010 überlappen sind
• Du verwendest Kanal-Nummern %C% außerhalb von Kanälen

Ähm, ja ich habe nochmal nachgerechnet, habs jetzt nochmal neu aufgezogen.
Auch die %AID%_PT-DisplayContentText/Pict auf 8bit reduziert (1Byte, in der Firmware ist die kleinste Einheit eh immer ein Byte, daher hab ich mir das Aufbrechen in Bits erspart, keine Ahnung ob das OK ist oder ob das gravierende Nachteile mit sich bringt.)

DPT16 KOs benötigen 14 Bytes Größe. Eine Beschränkung der Text-Länge müsstest Du in der Firmware vornehmen, ggf. in Abhängig von geeigneten Konfigurationen zum Verhalten

Oh, ok. Ja hab grade nochmal nachgelesen, da steht tatsächlich "The length is fixed to 14 octets". Gibts ja gar ned, hätte man nur mal besser lesen müssen

Fakt ist, dass bei dem Display und der Größe die ich hier mal ausprobiert habe ab 8 Zeichen keinen Sinn mehr gibt, weil das Display zu klein ist. Und lesen soll man auch noch was können, also will ich den Text nicht beliebig klein machen.

Ich möchte auf jeden fall eine Funktion einbauen, mit der man den Text auf den Displays temporär überschreiben kann. Das ganze würde ich selbstrückstellend ausführen, sprich ich überschreibe den Displaytext mit einem anderen Text und nach 5 sek oder so wird der temporäre Text wieder gelöscht und der normale text erscheint wieder.
Das soll vor allem mit den Pictogrammen so funktionieren, dass man z.b. das Icon für Licht beim Dimmen mit dem %-Value des aktuellen Levels rein schreibt (geht das mit dem Integrierten Logikmodul?)

image.pngimage.png

Für den Konfigurationsblock solltest Du noch einen eindeutigere Benennung finden (ohne Config) und ein eindeutige Icons. Auf der obersten Ebene sollten diese ebenfalls eindeutig sein.

Ja stimmt, da muss ich nochmal GIMP und all meine Design-Skills aufbringen um ein Icon zu basteln
Für die Benennung evtl "Hardware Config"? Fällt mir Spontan jetzt nichts besseres ein...

%AID%_PT-LEDColors: Was für eine Codierung verwendest Du da? Farbwinkel in 8Bit? Wäre eine freie Farbwahl möglich ist von Hardware-Seite und Du diese erlauben willst, dann würde ich empfehlen die Auswahl für externes KO abzutrennen.

Jo genau, Farbwinkel 8-Bit, wie in der FastLED Library.

Wie meinst du die Auswahl für externes KO abtrennen? Dachte halt eher so "entweder du nimmst eine voreingestellte Farbe oder du sendest mir eine Farbe über den Bus"

%AID%_PT-DisplayContentPict: Sind das extern vorgegebene Werte?

Naja, ich würd halt vorgegebene Icons in die Firmware fest reinprogrammieren und die kann man dann halt auswählen... Kann man dann immer noch mit "custom" erweitern, aber fürs erste muss das Ding wie gesagt mal irgendwas tun

%AID%_PT-CAPSensitivity: Warum so herum codiert?

Weil das die gleiche Reihenfolge wie der enum im C-Code ist... einfach so übernommen.

Gibt es einen besonderen Grund warum Du keine Unions für die Parameter-Definition verwendest? Du hast zwar aktuell keine überlappenden alternativen Parameter, die Erfahrung hat jedoch gezeigt dass Du mit deren Einsatz flexibler bist, u.A. mit Blick auf wiederholende Strukturen.

Jup, gibt es, verstehe nicht was es macht, ganz einfach


Man muss auch dazusagen, dass die Software bei dem ganzen Projekt mit abstand mein persönlicher Schwachpunkt ist. Ich bin schon etwas bewandert in C/C++ bzw. Programmierung allgemein, aber definitiv weit unter dem gefühlten Level der ganzen Profis hier

[traxanos]

Ja stimmt, da muss ich nochmal GIMP und all meine Design-Skills aufbringen um ein Icon zu basteln

Also wir haben uns intern darauf geeinige keine Icons zu machen, damit wir alle einen gleichen Stil haben. Wir verwenden MDI Icons exportiert als 32x32 und übernehmen den Namen des Icons (ohne das "custom_" am Anfang wegen dem custom export in 32x32).

https://pictogrammers.com/library/mdi/

[mumpf]

Das soll vor allem mit den Pictogrammen so funktionieren, dass man z.B. das Icon für Licht beim Dimmen mit dem %-Value des aktuellen Levels rein schreibt (geht das mit dem Integrierten Logikmodul?)

Ist IMO nicht den Anwendungsfall für das Logikmodul, so eine Spezialbehandlung sollte in die Applikation/Firmware.
Aber ab der nächsten (evtl. übernächsten) Version vom Logikmodul wird man sich einen DPT16 zusammenbasteln können (also aus "T: %E1:0,02%°C" wird dann "T: 22,75°C"). Die Formatiersprache steht noch nicht ganz fest, wird aber das aus printf bekannte sein, ergänzt durch Eingänge, Ausgang und Benutzerformeln.

Gruß, Waldemar

[coko]

Auch die %AID%_PT-DisplayContentText/Pict auf 8bit reduziert (1Byte, in der Firmware ist die kleinste Einheit eh immer ein Byte, daher hab ich mir das Aufbrechen in Bits erspart, keine Ahnung ob das OK ist oder ob das gravierende Nachteile mit sich bringt.)

Das Extrahieren der Einzel-Bits bringen die Makros für den Parameter-Zugriff mit. Damit musst Du Dich nur auseinandersetzen, wenn Du an den Standardmakros vorbei auf die Parameter zugreifen willst, und das solltest Du nur tun wenn Du wirklich gute Gründe dafür hast. Alles was Du an Parametern definierst muss beim Programmieren der Konfiguration über den Bus übertragen werden und verlängert somit die Programmierzeit. In Deinem aktuellen kleinen Modul (aktuell ~30Byte) wird man das nicht spüren, aber in größerer Anzahl (viele Kanäle und viele Parameter je Kanal) kann das schon erheblich werden: Ich denke im Fall der State-Engine/DFA-Modul (~1KB/Kanal) sogar drüber nach längerfristig einen 8Byte-Typ auf 7 Bit zu reduzieren, weil dieser in mehreren Tausend Instanzen benutzt wird. (Das ich das nicht von Anfang an gemacht habe liegt an anderen Optimierungen, die damit im Konflikt stehen)

dass bei dem Display und der Größe die ich hier mal ausprobiert habe ab 8 Zeichen keinen Sinn mehr gibt, weil das Display zu klein ist. Und lesen soll man auch noch was können, also will ich den Text nicht beliebig klein machen.

Ging mir da gar nicht um kleiner, sondern um Alternativen zur Darstellung von 14Byte Text auf einer Ausgabe mit nur 8 Zeichen Länge. Dafür gibt es verschiedene Möglichkeiten (ohne Anspruch auf Vollständigkeit):

• Abschneiden ud Ignorieren der Zeichen 9 bis 14 (Möglicher Informationsverlust)
• Zeichenweise durchscrollen bis zur Anzeige von Zeichen 7 bis 14 (eher unruhig, mögliche Verkürzung bei weniger als 14 Zeichen)
• Anzeige in zwei Teilen "1234567…" und "…89abcde" (unschöner Umbruch)

Für die Benennung evtl "Hardware Config"? Fällt mir Spontan jetzt nichts besseres ein...

Auf keinen Fall "Hardware Config", da es bereits ein gleichnamiges (in der ETS nicht sichtbares) OpenKNX-Modul gibt. Das sollte ein sprechender Name dafür sein was konfiguriert wird. Aus Deinen Beschreibungen lese ich bislang folgenden Konfigurationsbedarf heraus:

• Basiseinstellungen für den Touch-Controller (aktuell "Touch-Sensing")
• Anzeige
  • Basiseinstellungen
  • je Beschriftung (für Links und Rechts identisch)

Die Herausforderung besteht darin hier eine gute Lösung zur Konfiguration in der ETS zu finden, u.A. zum Zusammenspiel zwischen Tastern und Anzeige. Evtl. wäre hier sogar eine Aufteilung in mehrere Module sinnvoll. Gehe davon aus, dass mehrere Iterationen erforderlich sind bis Du eine saubere Oberfläche hast. Es kann durchaus helfen auch mal einzelne Details in verschiedenen Varianten zu Skizzieren, bevor Du eine Umsetzung in der ETS vornimmst:

Ich möchte auf jeden fall eine Funktion einbauen, mit der man den Text auf den Displays temporär überschreiben kann. Das ganze würde ich selbstrückstellend ausführen, sprich ich überschreibe den Displaytext mit einem anderen Text und nach 5 sek oder so wird der temporäre Text wieder gelöscht und der normale text erscheint wieder.
Das soll vor allem mit den Pictogrammen so funktionieren, dass man z.b. das Icon für Licht beim Dimmen mit dem %-Value des aktuellen Levels rein schreibt (geht das mit dem Integrierten Logikmodul?)

Display einschalten:            (*) dauerhaft   ( ) nur bei Annäherung/Präsenz
Standardtext-Definition:        (*) fest    ( ) über KO
  Standardtext:                 [        ]   # 8 Zeichen
Icon-Definition                 (*) fest    ( ) über KO
  Icon                          [ ... |V]    # kein (0) / Lampe An (1) / Lampe Aus (2) / ... reservierte nicht zeigen ... / ...  eigenes Icon (x) ..
Status-Ausgabe bei Bedienung:   ( ) nein    (*) ja
  Anzeigedauer (0=Zentralwert): [  5] s
  Typ                           [ Prozent |V]                      
  Icon                          [ ... |V]    # unverändert / kein / ...

Naja, ich würd halt vorgegebene Icons in die Firmware fest reinprogrammieren und die kann man dann halt auswählen... Kann man dann immer noch mit "custom" erweitern, aber fürs erste muss das Ding wie gesagt mal irgendwas tun

Das hört sich sinnvoll an. Vorschlag (siehe auch oben), jeweils in der Auswahl mit Dezimalwert kennezeichnen der auch die Auswahl über den Bus erlauben würde:

• 0 für kein Icon
• 1..f für Icons in der Firmware
• f..F reserviert fü weitere Icons in der Firmware - nicht in Auswahllisten in der ETS aufnehmen und über den Bus ignorieren?
• F+1..255 für eigene Icons

Wie meinst du die Auswahl für externes KO abtrennen? Dachte halt eher so "entweder du nimmst eine voreingestellte Farbe oder du sendest mir eine Farbe über den Bus"

Zwei Parameter verwenden:

...
Farbdefinition:                 (*) fest    ( ) über KO
  Farbe                         [ ... |V]    # oder ETS-Farbauswahl
...

Dann hast Du einen klares Muster in der UI für Werte die Du direkt angibst und über KO entgegennimmst, kannst ohne Bitoperationen oder Fallunterscheidungen in der Firmware die beiden Fälle unterscheiden, und könntest z.B. für den Fall "über KO" auch noch leichter eine Konfiguration erlauben die festlegt was passieren soll wenn noch kein Wert vom Bus vorliegt. Btw.: Eine Standardwert an dieser Stelle wäre ein Fall für mehrfache Nutzung des selben Parameter-Speicherbereichs, bzw. mehrfacher Referenzierung.

Weil das die gleiche Reihenfolge wie der enum im C-Code ist... einfach so übernommen.

Dein Code oder Bibliothek? Bei freier Wahl kannst Du Dir das Leben mit geschickter Definition ggf. einfacher machen und solltest jeweils überlegen, für die Standardoption den Wert 0 zu wählen, wenn das nicht für eine deutlich komplliziertere Implementierung sorgt (was hier der Fall wäre).

Hardwaretechnisch kann der CAP1188 insgesamt 8 Tasten. Ich brauche/möchte evtl. eine für eine Proximity-Detection, da muss ich aber mal gucken ob ich die "proximity" auch einfach intern ausrechnen kann.

Dann wäre es toll die Anzahl nicht künstlich auf 4 zu beschränken. Mit 7+1 könnte man z.B. auch eine wabenförmige Anordnung on Tastflächen realisieren. Ein Großteil Deiner Funktionalität ist vom Erscheinungsbild vollkommen unabhängig.

Alles nur Vorschläge und teilweise auch eher was zum vorab Mitdenken, um späteren Änderungsbedarf zu reduzieren. Mache Dich da nicht verrückt und schau erst mal, dass Du einen laufenden Prototyp hast. Dann kann man weitersehen. Die veröffentlichten OpenKNX-Lösungen sind alle nicht von heute auf morgen entstanden.

In diesem Sinne nun ersteinmal frohe Ostern!

[cad435]

Danke für die ganzen Hinweise coko

Vor allem das

Code:

gefällt mir sehr gut!

Und auch die Idee mit den Waben gefällt mir gut...
Demnächst gehts erstmal wieder bisschen mit der Hardware weiter, hatte über die Feiertage ein paar teile Alu bestellt zum fräsen.

Zusätzlich würde ich gerne mal alles auf GitHub hochladen. Da ich absoluter Anfänger in Git Sachen bin (nutze zu 99% grafische Oberfläche von Github) muss ich mir das erstmal ansehen wie das mit dem "verlinken" auf externe Module geht (Die ganzen OAM-Module etc.)

Edit: Sieht zumindest auf den ersten Blick genauso aus wie ein existierendes OpenKNX repo
https://github.com/cad435/TAS-UP-4x-TouchRGB

Schöne Ostern euch

- cad435

Oh, noch eine Nachgestellte frage:
Als ich das erste mal meine Sourcen kompiliert habe über das Powershell -Skript, da musste ich bei großej teilen des skripes bei den Pfadangaben immer um einen Pfad zurückspringen

../

Also zum Beispiel in der "scripts\Build-Release.ps1" datei musste ich aus dem ersten Aufruf ein

../lib/OGM-Common/scripts/setup/reusable/Build-Release-Preprocess.ps1 $args[0]

machen.

Das zog sich durch einen Haufen skripte durch und ist sicherlich nicht so gewollt

Was mache Ich hierbei falsch?

[mumpf]

Was mache Ich hierbei falsch?

Das ist schwer zu sagen... ich war ja nicht dabei, als Du es gemacht hast . Wäre aber interessant, das herauszufinden, damit es anderen nicht passiert.

Wenn Du ein Projekt von uns nutzt, legst Du einen Root-Ordner an (bei uns heißt der OpenKNX, muss aber nicht). In diesen Ordner machst Du ein Clone vom OAM-xxx, dass Du nutzen willst. Dann machst Du ein cd OAM-xxx\restore. Dort führst Du das Restore-Script aus (zum weiterentwickeln das mit -Branch am Ende). Das cloned Dir alle benötigten Module in den OpenKNX-Ordner.
Und dann passen alle Pfade.

Jetzt kannst Du uns sagen, was Du anders gemacht hast....

Gruß, Waldemar

[cad435]

Soweit genau so!

Funktioniert auch soweit.

Ich vermute, dass die ps1 skripte bei euch irgendwie aus dem "Haupt"-Ordner (z.b. SEN-UP1-8xTH) ausgeführt werden.
Dann würde nämlich der Aufruf im Orginalscript (Build-Release.ps1, Zeile 30) in den richtigen Pfad

SEN-UP1-8xTH/lib/OGM-Common/scripts/setup/reusable/Build-Release-Preprocess.ps1

zeigen.

Wenn man aber nun in den "scripts" Ordner hineingeht und das Script Build-Release.ps1 ausführt, dann wird das in meinem Beispiel im Ordner "SEN-UP1-8xTH/scripts" ausgeführt. Das heißt der Aufruf in Zeile 30 zeigt jetzt auf

SEN-UP1-8xTH/scripts/lib/OGM-Common/scripts/setup/reusable/Build-Release-Preprocess.ps1

Und die Dateien findet er halt nicht.

Grüße
- cad435

[coko]

Zitat von coko Beitrag anzeigen

• Bei Text-Parametern musst Du berücksichtigen, dass diese als Null-terminiert erwartet werden. Im Speicherlayout daher noch ein leeres Byte (befüllt mit 0x00) dainter freilassen, ansonsten müsstestDu in der Firmware eine besondere Behandlung für das Fehlen bei Maximallänge vorsehen.

Das gibt absolut Sinn, hab ich so eingebaut, Danke!

Du hast den Parameter-Typ jetzt auf 72Bit verlängert. Das führt aber zu einem anderen Ergebnis: Die ETS erlaubt dort nun die Eingabe von 9 Zeichen. Du müsstest stattdessen an der Speicherstelle hinter dem Parameter für ein Null-Byte sorgen (Bei Vorbelegung des Speichers mit 0 hinter der Zeichenkette ein Byte frei lassen), oder bei der Verarbeitung der Zeichenkette auf die erlaubte Maximallänge beschränken.

[cad435]

Ja ich bin da grad auch nochmal drüber gefallen.
Also nur zum Verständnis:

Ich nehme den ParameterType mit 8Bytes zeichen, damit lässt mich die ETS 8 Bytes eintragen.
In der MemoryMap also bei <Parameters> baue ich mir den Offset dann mit 9bytes zusammen, sodass immer mindestens 1 Byte für die Nullterminierung frei bleibt.

Im KO werden aber bis zu 14Byte gesendet, das hat aber erstmal NICHTS mit dem Parameter zu tun, ja?
Das "abschneiden" (es wird wohl abschneiden werden) muss ich in der firmware machen, sodass ich den Parameter dann wieder aus der Firmware heraus mit max 8 Zeichen + Nullterminierung beschreiben kann.

So korrekt verstanden?

[coko]

In der MemoryMap also bei <Parameters> baue ich mir den Offset dann mit 9bytes zusammen, sodass immer mindestens 1 Byte für die Nullterminierung frei bleibt.

Empfehle an dieser Stelle das Byte, bzw. auch an allen anderen freien Stellen im Speicherlayout die ungenutzten Bits zu dokumentieren. Das ist in Unions ggf. noch etwas übersichtlicher und mit einem entsprechend großen Union vermeidest Du auch Sonderfälle am Ende des Moduls oder Channels bei dem Producer im Rahmen der Offset-Berechnung für nachfolgende Einträge den gewünschten Freiraum verschlucken würde (die Information liegt halt nicht strukturiert vor).

Im KO werden aber bis zu 14Byte gesendet, das hat aber erstmal NICHTS mit dem Parameter zu tun, ja?

Korrekt. KO-Textewerte und Parameter sind vollkommen unabhängig. In den Parametern können auch ganz andere Dinge drin stehen wie z.B. Geräte-Seriennummern oder URLs.

Das "abschneiden" (es wird wohl abschneiden werden) muss ich in der firmware machen, sodass ich den Parameter dann wieder aus der Firmware heraus mit max 8 Zeichen + Nullterminierung beschreiben kann.

Das Kürzen einer über KO eingegangenen Zeichenkette auf maximal 8 Zeichen zur Weiterverarbeitung, bzw. die Limitierung bei der Verarbeitung, muss Du individuell in der Firmware implementieren.

Ich verstehe allerdings nicht warum Du den Parameterwert aus der Firmware verändern willst. Was ist Dein Ziel dabei?

[cad435]

Ich verstehe allerdings nicht warum Du den Parameterwert aus der Firmware verändern willst. Was ist Dein Ziel dabei?

Hmm, ja ich will den empfangenen Text anzeigen.

Also ich hätte dann wohl eher schreiben sollen "Variablenwert verändern".

Gibt es eine Dokumentation zu den unions?

Ich kenne Unions in C/C++, verwende sie allerdings nicht wirklich. Sind die XML-Unions quasi gleich? In C kann ich damit ja einfach verschiedene Bits/Nibbels/was weis ich in einen Speicherbereich bündeln und dann halt damit arbeiten.

Warum ist das hier empfohlen? Nur um die Strukturierung besser zu gestalten? Weil theoretisch könnte ich auf den Byte und Bitoffset manipulieren.
Wie gesagt, Die Unions sind mir noch nicht ganz griffig...
Bisschen was hat coko oben schon geschrieben, aber naja... Mein Knoten im Hirn möchte sich noch nicht lösen.

- cad435

[Ing-Dom]

Ich vermute, dass die ps1 skripte bei euch irgendwie aus dem "Haupt"-Ordner (z.b. SEN-UP1-8xTH) ausgeführt werden.

die skripte werden eigentlich nur über VSC Tasks aufgerufen, nicht direkt.

[thewhobox]

Sind die XML-Unions quasi gleich?

Unions sind ähnlich aber nicht gleich.
Normal darfst du nicht mehrere Parameter an der selben Stelle speichern (auch wenn diese nicht zeitgleich aktiv sind).
Das Problem kann man mit Unions umgehen, da du dort beliebig viele Parameter drin speichern kannst.
Du kannst auch einen default Parameter angeben, der dort gespeichert werden soll, falls kein anderer Parameter in der Union aktiv ist.