Taster mit RGB Hintergrundbeleuchtung programmieren

[Olli]

Hallo,

ich möchte einen Taster haben, der maximal 6 Tasten (3Wippen) hat und durch milchiges Plexiglas von unten beleuchtet wird.
Die Hardware steht soweit, die Taster habe ich selbst gefräst (ähnlich wie http://shop.haus-bus.de). Das ganze aktuell für den Gira Standard System 55 Rahmen.
Die Platine des eigentlichen Tasters besitzt 6 5050 RGB LEDs, die von einem WS2803 per SPI vom LPC1115 angesteuert werden.
Als Controller Platine hatte ich mir die lpc1115_16io_up aus dem hardware-incubation Ordner ausgesucht.
(Hat die bereits jemand ausprobiert und ist so funktionsfähig?)

Der Clou ist, dass eine gepulste IR-LED und eine Photodiode mit Tageslichtfilter auf der Tasterplatine verbaut ist. Somit habe ich realisieren können, dass die LEDs nur angehen, wenn man die Hand vor den Taster hält.
Ich hatte mir folgenden Hintergrund überlegt:
Jede Funktion bekommt im gesamten Haus eine Farbe zugewiesen (z.B. Deckenleuchte = blau, Jalousie = grün...). Wenn man nun nicht mehr weiß, welcher Taster in einem Raum für eine bestimmte Funktion vorhanden war, kann man dieses durch die Farben erkennen.
Dieses soll mir die Beschriftung der Taster ersparen (da ich keine "schöne" Möglichkeit zum selber bauen gefunden habe...)

Zusätzlich sollen die LEDs als Nachtlicht bzw. Orientierungslicht nutzbar sein.

Daraus ergeben sich folgende Anforderungen an die Programmierung des KNX Teils:
6 x 3 x 8 Bit Farbwert (6 LEDs, 3 Farben/LED, 8 Bit pro Farbe) schreiben
1 x 3 x 8 Bit Farbwert für Nachtlichtfunktion schreiben
6 x Taster auslesen
Funktion "Handerkennung" ein- und ausschalten
Funktion "Nachtlicht" ein- und ausschalten
evtl. Helligkeit auslesen (muss noch evaluiert werden, da Photodiode mit Tageslichtfilter verbaut)

Ich habe die Funktionen bereits mit der sblib programmiert, sodass der Einstieg bereits gemacht ist.
Leider habe ich noch nicht allzuviel Ahnung, wie ich dieses Projekt in die KNX Welt einbinden kann (und später auch per ETS programmieren kann...)

Eventuell ist hier der ein oder andere, der auch Interesse an diesem Taster und bereits Erfahrung mit der Programmierung von KNX Komponenten hat. Ich bin selbstverständlich bereit alle Sourcen und auch CAD Zeichnungen für die Tasterkomponenten und Platinen hier oder im GIT zu veröffentlichen.
(Man möge mir einen Zugang geben)

Ich hoffe, wir bekommen das Projekt zusammen hin.

Grüße
Olli

[oldcoolman]

Zugang ist sicherlich kein Ding. Die Zahl der Objekte ist etwas hoch wenn man die RGB durch 3 getrennte Objekte ansteuern wollte. Es gibt allerdings RGB Objekt in 3 Byte Ausführung mittlerweile. Ob das Ganze in BCU1 passt bin ich mir noch nicht sicher.

[Olli]

Hallo,

ich habe durch Zufall einen neuen Taster von MDT entdeckt, der genau das kann, was ich realisieren möchte.
http://www.mdt.de/Glastaster_Smart.html

Da ich bisher "nur" die normale Mikrocontroller Programmierung und keinerlei Erfahrung mit KNX Innereien habe, möchte ich fragen, wie es wieter gehen sollte.

Ich denke, ich muss die vd Datei dieses Tasters auseinandernehmen und dort nachsehen, mit welchen Kommunikationsobjekten dieser Taster arbeitet?!

Wie genau stelle ich das an?

Da es für diesen taster noch keine Produktdatenbank gibt, wollte ich eine andere von MDT mir ansehen.

Die vd4 Datei des Tasters http://www.mdt.de/Glastaster.html ist per ZIP nicht zu öffnen. Dort wird ein Passwort verlangt.

Wie ihr seht, würde ich gerne in die Programmierung neuer Selbus Komponeten einsteigen, habe auch Programmiererfahrung, komme aber nicht so recht an den Start mit den KNX spezifischen Dingen.

Über eine kleine Anleitung der nächsten Schritte würde ich mich sehr freuen.

Grüße
Olli

[Florian]

vd4 sind in der Tat mit einem Passwort versehen. Aber waren die Dateien da drin nicht Binärdateien?

Mein Vorschlag: Hol die die .knxprod Datei. Das ist eine unverschlüsselte zip-komprimierte Datei. Und die Dateien da drin sind .xml, die man nach ein wenig Eingewöhnung direkt lesen kann.

Nehmen wir z.B.
http://www.mdt.de/download/MDT_KP_Glast ... 0a.knxprod

Im Hauptverzeichnis befindet sich die Signatur, der Grund, warum man diese Dateien nicht ohne weiteres selbst schreiben kann.

Wirklich interessant sind die xml im Unterverzeichnis, hier beginnen sie mit M-0083* Davon gibt es vier, sie beschreiben die Konfigurationsdaten für 4 verschiedene Geräte.

Die 0083 ist die Hersteller ID, die nächste 4 stellige Hex-Zahl die Device ID. Damit wird ein Gerät von der ETS identifiziert.

Weiter in den XML:
- Es beginnt gleich mit der Beschreibung der Code-Segmente zwischen <Code> und </Code>. Die Segmente sind hier mit Adresse und Größe beschrieben. <Data> und <Mask> beschreibt einen Default-Inhalt in Binär. Unter der angegebenen Id, z.B. "M-0083_A-0084-10-E9BD_AS-4000" findest Du weiter in der Datei den Aufbau des Segments. Nach obiger Id gesucht siehst Du also, dass es sich um die Addresstabelle handelt. Mit maximal 255 Einträgen. Jeder ist 2 Byte lang, dazu 3 Byte anderes und das ergibt die angekündigte Länge von 513 Bytes.
- Wirklich interessant ist wohl eher das Segment "M-0083_A-0084-10-E9BD_AS-4400". Denn das Applikationsprogramm, so heißt bei KNX die Konfiguration (also nicht Programm wie Firmware), wird hier Byte für Byte beschrieben.
- "Offset" beschreibt den Offset innerhalb des Segments. 4400+360 würde also als Zeiladresse im User-Eeprom 4760 ergeben.
- "SizeInBit" beschreibt, wie viele Bytes in diesem Punkt beschrieben werden, denn es werden Vielfache eines Bytes gleichzeitig beschrieben.
- Darin können mehrere Optionen kodiert sein, Dropdown-Menüs, Ja/Nein-Optionen oder Zahlenwerte.
- Die Funktion kann man anhand der vorkommenden Bezeichnungen meist erraten.
- Mehrere Optionen auf den selben Bits bedeutet üblicherweise, dass es sich um sich ausschließende Unterkonfigurationen eines Betriebsmodus handelt. (z.B. bei einem Gerät mit Relaisausgängen "Schaltaktor" "Heizungsaktor". Da können die Bits je nach Betriebsmodus anderes bedeuten. Das ist nicht auf eine "große Modusumschaltung" beschränkt. Jede Option kann das prinzipiell auslösen. Klingt kompliziert, aber in der ETS kann man das ja leicht nachvollziehen.)
- "access=none" bezeichnet irgendwelche internen Felder, habe ich nicht weiter verfolgt.
- die Suche nach dem angegebenen ParameterType, z.B. "M-0083_A-0084-10-E9BD_PT-ui.5FunsignedChar" ergibt viel weiter oben in der Datei eine nähere Definition dieses Eingabefeldes. Hier konnte man es auch schon am Namen erraten: Eine Zahl zwischen 0 und 255.

So kann man sich Stück für Stück durch eine solche Gerätebeschreibung durchfinden. Aber es gibt eine böse Falle: Der Hersteller kann neben einer .knxprod für sein Gerät zusätzlich ein Plugin verwenden. Das Plugin kann beim Download die Daten umschreiben. Von ABB ist mir dieses Verhalten bekannt. Dann stimmen die Daten, die beim Gerät ankommen, nicht mit der Beschreibung in der xml überein. Zum Glück ist es trotzdem sehr ähnlich was ankommt..

Soviel für's erste, schnell zusammengetippert...

[Olli]

Hallo,

@Florian: vielen Dank für die ausführliche Einleitung.

Ich habe einiges mehr verstehen können und habe angefangen bereits existierende Programme von hier mit der passenden knxprod zu entschlüsseln.

Was mir allerdings noch Probleme bereitet, ist die Angabe, welche Busankopplerversion (BCU1, BCU2 oder auch BIM112) für ein gewisses Produkt verwendet wird und wie dieses zu erkennen ist.

Gibt es eigentlich eine Möglichkeit den gesamten Speicherinhalt eines mittels ETS konfigurierten Selfbus KNX Gerätes auszulesen?
Ich meine also beispielsweise über eine serielle Verbindung den Inhalt des userEeprom ausgeben zu lassen?
Somit könnte man kleine Veränderungen in der Konfiguration mittels ETS vornehmen und sehen, welche Bits sich im Eeprom verändern.

Grüße
Olli

[oldcoolman]

War bei der ETS3 ein extra programm mit dabei. deviceeditor.
Damit hat ja irgendwie alles angefangen
Für den LPC922 hab ich dann ein sniffer geschrieben gehabt, der über uart den Inhalt ausgab.
War viel schneller und geänderte Bytes erschienen rot.
Das war aber nur BCU1 also 256 Byte.

[Florian]

Hallo,
Was mir allerdings noch Probleme bereitet, ist die Angabe, welche Busankopplerversion (BCU1, BCU2 oder auch BIM112) für ein gewisses Produkt verwendet wird und wie dieses zu erkennen ist.

Gibt es eigentlich eine Möglichkeit den gesamten Speicherinhalt eines mittels ETS konfigurierten Selfbus KNX Gerätes auszulesen?
Ich meine also beispielsweise über eine serielle Verbindung den Inhalt des userEeprom ausgeben zu lassen?
Somit könnte man kleine Veränderungen in der Konfiguration mittels ETS vornehmen und sehen, welche Bits sich im Eeprom verändern.

Die Busankopplerversion ist in der Maskenversion kodiert. In der .xml gibt es beim <ApplicationProgramm> die
MaskVersion=
Nun muss man wissen, dass die *70* für BIM112 steht
*01* für BCU1
*02* für BCU2

Das steht z.B. in Busdevices_E0608c.pdf von knx.org (einfach nach dem Dateinamen googlen).

Und man kann auch mit Boardmitteln von der ETS ermitteln, welche Bits sich ändern. Man muss halt im Telegrammmonitor die Speicherzugriffe beobachten. Ist mühsam, geht aber.