Konfiguration von DIY-Geräten

[l0wside]

Konfiguration - Doku

Der Komplettumbau der Konfiguration war doch eine größere Sache als gedacht, ist aber inzwischen einigermaßen abgeschlossen. Inhaltlich werde ich nichts Großartiges mehr daran verändern, es kann aber passieren, dass der eine oder andere gesetzte Wert auch tatsächlich Berücksichtigung findet
Bis auf das Setzen der Kommunikationsflags habe ich versucht, zum BCU2 nach der Doku von Martin Kögler kompatibel zu bleiben. Getestet ist das ganze mit den eibd-Tools, funktioniert einwandfrei (außer dass writeaddress am Schluss noch eine Speicherstelle schreiben will, deren Bedeutung sich mir nicht erschließt).

Bei weitem nicht alle Parameter werden in der Applikation auch unterstützt/verwendet. Die Konfiguration kann trotzdem damit umgehen.

1. Schnittstelle zum Bus

• Access Control mit den Leveln ACCESS_NONE, ACCESS_FREE, ACCESS_USER und ACCESS_CONFIG. Die Schlüssel dazu sind allerdings hart kodiert. Konsequenz: man braucht zum Setzen der meisten Werte und zum Speicher schreiben den entsprechenden Key, bei mpropwrite & Co ist das der Parameter -k.
• Verfügbare Standardparameter (BCU2):
  • Object 0, Property 0x01: Device Object Type (PT_UNSIGNED_INT, RO)
  • Object 0, Property 0x0E: Device Control (PT_GENERIC01)
  • Object 0, Property 0x08: Device Service_control (PT_UNSIGNED_INT)
  • Object 0, Property 0x09: Device Firmware_revision (PT_UNSIGNED_CHAR, readonly)
  • Object 0, Property 0x0B: Device Serial Number (PT_GENERIC06)
  • Object 0, Property 0x0C: Device Manufacturer ID (PT_UNSIGNED_INT)
  • Object 0, Property 0x0F: Device Order Info (PT_GENERIC10)
  • Object 0, Property 0x10: Device PEI Type (PT_UNSIGNED_CHAR, readonly)
  • Object 0, Property 0x12: Device Poll Group Settings (PT_POLL_GROUP_SETTING)
  • Object 0, Property 0x11: Device Port Addressing (PT_UNSIGNED_CHAR)
  • Object 0, Property 0x13: Device Manufacture ID (PT_GENERIC04)
  • Object 1, Property 0x01: Address Table Object Type (PT_UNSIGNED_INT, readonly)
  • Object 1, Property 0x05: Address Table Load State Control. (PT_CONTROL). Ist eigentlich nicht notwendig, Schreibzugriffe auf die Tabelle beeinflussen das Geräteverhalten sofort.
    Object 0x01, Property 0x07: Address Table Reference (PT_UNSIGNED_INT). Liefert einen (einstellbaren) Dummy-Wert zurück, der dann bei einem anschließenden Speicherzugriff entsprechend behandelt wird.
  • Object 2, Property 0x01: Association Table Object Type (PT_UNSIGNED_INT, readonly)
  • Object 2, Property 0x05: Association Table Load State Control. (PT_CONTROL). Ist eigentlich nicht notwendig, Schreibzugriffe auf die Tabelle beeinflussen das Geräteverhalten sofort.
  • Object 0x02, Property 0x07: Association Table Reference (PT_UNSIGNED_INT, readonly). Liefert einen (einstellbaren) Dummy-Wert zurück, der dann bei einem anschließenden Speicherzugriff entsprechend behandelt wird.
  • Object 3, Property 0x01: Application Object Type (PT_UNSIGNED_INT, readonly)
  • Object 3, Property 0x05: Application Load State Control (PT_CONTROL). Wert ist eigentlich nur bei der klassischen Trennung BCU/Applikation sinnvoll, bei integriertem Busankoppler weniger.
  • Object 3, Property 0x06: Application Run State Control (PT_CONTROL)
  • Object 3, Property 0x10: Application PEI type (PT_UNSIGNED_CHAR, readonly). Auch nur für getrennte BCU sinnvoll.
  • Object 3, Property 0x0D: Application Version (PT_GENERIC05, readonly)
  • Object 3, Property 0x07: Application Table Reference (PT_UNSIGNED_INT). Faktisch nicht unterstützt, die Konfiguration der Applikation geschieht rein über Properties.
  
  
• Applikationsspezifische Parameter
  Hier herrschen natürlich mehr Freiheitsgrade. Als Konvention gesetzt und implementiert ist der feste Zusammenhang zwischen Kommunikationsobjekt und Property Object, und zwar wie folgt:
  • Object x, Property 0, Index 0: Flags (PT_UNSIGNED_CHAR). Es gilt: K=1, L=2, S=4, A=8, Ü=16 (enstprechend BCU2)
  • Object x, Property 0, Indizes 1...n: assoziierte GA (PT_UNSIGNED_INT). Dies ist eine alternative (und m.E. einfachere) Zugriffsmöglichkeit auf Address und Association Table. Zugriffe über dieses Interface werden auf die beiden Tables transparent umgesetzt.
  • Object 255: Debug Object. Verwendet, um interne Statuswerte oder Rohdaten auszulesen.
  
  

2. Verwendung durch den User
Die allermeisten o.g. Werte muss man nie anfassen. Es genügt, die GAs und die Flags zu setzen und das Gerät zu parametrieren. Dafür reichen die eibd-Tools mpropwrite und writeaddress. Ich beschreibe die Prozedur exemplarisch für den KNX-Multisensor (von einem Gerät mit lokal laufendem eibd aus).

1. PA setzen: Gerät an den Bus, Programmierknopf drücken, LED leuchtet. Auf der Kommandozeile writeaddress local:/tmp/eib 1.2.34 eingeben, warten. Wenn die LED ausgeht, ist die Adresse geschrieben. Eine Fehlermeldung von writeaddress kann man ignorieren - wenn die LED ausgeht, ist alles i.O.
2. Flags für das KO 10 setzen. Das geht mit mpropwrite und dem entsprechenden Key, hier 0xDEADBEEF:
   mpropwrite -k 0xDEADBEEF local:/tmp/eib 1.2.34 10 0 0 1 1F - setze bei Object 10, Property 0, Index 0 genau einen Wert, nämlich 1F (alle Flags gesetzt)
3. Gruppenadressen setzen, beispielhaft 3/4/56 und 4/5/67. Dazu müssen diese erst mal in Hex umgerechnet werden, dabei hilft der Rechner von Fa. Tapko (Umstellen auf "3 level addresses" nicht vergessen). 3/4/56 gibt 1C38, 4/5/67 gibt 2543.
   Diese Werte können nun mittels mpropwrite an Object 10, Property 0, Indizes 1 und 2 gesetzt werden. Das geht so:
   mpropwrite -k DEADBEEF local:/tmp/eib 1.2.34 10 0 1 2 1C 38 25 43 - setze Object 10, Property 0, ab Index 1 zwei Werte, nämlich 1C 38 und 25 43.
4. Applikation parametrieren. Der KNXMS hat bei Object 10, Property 1 sein Sendeintervall (in Sekunden). Hier muss man ein bisschen aufpassen, denn der verwendete µC hat Little Endian, d.h. erst das kleinere Byte, dann das größere Byte. Das ist ziemlich unintuitiv.
   60 Sekunden sind 0x3C, als Integer 003C - bzw. als Little Endian 3C00. Das wird nun zu
   mpropwrite -k DEADBEEF local:/tmp/eib 1.2.34 10 1 0 1 3C 00
5. Fertig, Baustein sendet und antwortet.

3. Verwendung in der Applikation
Dazu schreibe ich einen separaten Post.


Max

[Bernator]

Gratulation zum bisher Erreichten, beeindruckend
Wie Umfangreich ist der Stack denn als Ganzes, was wird an Hardware verwendet (Timer, Interrupts???) Ist es denkbar das auf den Arduino zu portieren?

[l0wside]

Gratulation zum bisher Erreichten, beeindruckend
Wie Umfangreich ist der Stack denn als Ganzes, was wird an Hardware verwendet (Timer, Interrupts???) Ist es denkbar das auf den Arduino zu portieren?

Der Stack (auf Anfrage verfügbar) hat rund 3000 LOC (reines C), zusätzlich muss man noch ein paar µC-spezifische Funktionen implementieren (ca. 500 LOC, Vorlage kann ich liefern) und der Konfigurationskram (etwa 800 Zeilen, werde ich hier im Forum zur Verfügung stellen). Doxygen-Doku ist für die Schnittstellen verfügbar.

Ich verwende einen MSP430 mit einem TPUART2, ich weiß aber auch von einer laufenden Portierung auf PIC mit NCN5120. Der Stack ist prozessorunabhängig geschrieben und sollte auf 16-bit Little-Endian-Systemen problemlos laufen. Auf einem 32-bitter (ARM) könnte es wegen Word Alignment noch ein paar kleinere Probleme geben, die sich aber lösen lassen.

Ein gewisses Verständnis für µC-Programmierung setze ich voraus. Wer nur mal ein bisschen was auf dem Arduino gemacht hat, wird mit dem Stack nicht glücklich werden. Timer und Interrupts (z.B. für die serielle Kommunikation) werden ausführlich verwendet.

Max

[l0wside]

Der Sourcecode zur Konfiguration

Wie versprochen, anbei der (mit wenigen Ausnahmen getestete und funktionierende) Sourcecode für die Konfiguration. Die Verwendung hatte ich ja schon ein paar Posts weiter oben beschrieben.

Enthalten sind zwei Sätze an Dateien:

• configuration.c, configuration.h. Hier ist das Handling der BCU2-Daten (einschließlich Verwaltung von GAs und PA) implementiert.
• appconfig.c, appconfig.h. Hier sind Anpassungen auf die jeweilige Applikation vorzunehmen. Der untere Teil von appconfig.c ist ebenfalls allgemein, nur im oberen Teil sind Anpassungen notwendig.

Doxygen-Doku ist für den allgemeinen Teil dabei (auf "Files" klicken). Am kompliziertesten ist vermutlich das Konzept der Configuration Description. Diese entkoppelt die eigentlichen Konfigurationsdaten im Speicher (z.B. bcu2_configuration) von ihrer Beschreibung. Damit hat der Stack eine transparente Möglichkeit, auf die Daten zuzugreifen.

Viel Erfolg damit, Rückfragen beantworte ich gerne (soweit möglich). Ein paar Anpassungen werden notwendig sein (z.B. fehlt die knx.h, die crid_t definiert), aber das sollten keine unlösbaren Probleme sein.

Das Design ist insgesamt mäßig elegant. Es wäre besser gewesen, die applikationsspezifischen Teile per Include mit in den allgemeinen Struct zu packen. Das ist mir aber erst aufgefallen, als der Code schon funktionierte, und dann habe ich ihn nicht mehr angefasst.

Getestet ist das alles gegen die eibd-Progrämmchen (mwrite, mread, mpropwrite, mpropread, writeaddress, xpropwrite). Lässt sich sicher auch auf ETS anpassen, wenn man eine passende Applikation hat, aber dafür war ich bis jetzt zu faul.

Max

EDIT: vergessenen Anhang eingefügt.

[l0wside]

Push.
Besteht (außer bei denen, die im Hintergrund beteiligt sind) überhaupt noch Interesse an dem Thema? Der Code für die Konfiguration ist inzwischen grundlegend überarbeitet und wäre reif für eine erste Veröffentlichung. Gefühlt führe ich hier aber einen Monolog...

Max

[Bernator]

Ich glaube die wenigsten sind wirklich so tief in der Sache drin um hier konstruktiv was beisteuern zu können

[Bernator]

Hallo Max,

kurze Zwischenfrage: Wie werden GA wieder gelöscht und KO zuweisungen aufgehoben?

PS: hatte jetzt mal wieder etwas zeit (schüttung drin ) und hab die repeated behandlung eingebaut, schick dir dazu demnächst was....

[l0wside]

Hallo Max,

kurze Zwischenfrage: Wie werden GA wieder gelöscht und KO zuweisungen aufgehoben?

PS: hatte jetzt mal wieder etwas zeit (schüttung drin ) und hab die repeated behandlung eingebaut, schick dir dazu demnächst was....

Gratulation zum Baufortschritt - Schüttung heißt Estrich? Dann hast du ja erst mal viel Zeit, auf der Baustelle bist du jetzt unerwünscht

Für das Löschen von GA gibt es zwei Möglichkeiten:

• Über das Property-Interface. Dazu in den entsprechenden Property-Index 00 00 reinschreiben, das ist für den Sensor "nicht zugewiesen".
• Über das Memory-Interface. Hier reicht es, die Association Table entsprechend zu modifizieren.

Ich arbeite gerade an einem Java-Tool zur Konfiguration, dauert aber noch ein paar Tage. Das Gewürge mit mpropwrite & Co ist ja keinem normalen Menschen zuzumuten.



Max

[Bernator]

Danke nicht ganz, is das zeug unterm estrich und muss auch bissl trocknen, jetzt am we fbh rein und dann nächste woche estrich...

• Über das Property-Interface. Dazu in den entsprechenden Property-Index 00 00 reinschreiben, das ist für den Sensor "nicht zugewiesen".

Damit wird aber im Address Table die Adresse 0/0/0 angelegt, nicht weiter schlimm aber der Association Table wird dann im verlauf der Zeit mit verweisen auf diese Adresse zugemüllt, oder hab ich einen denkfehler?

• Über das Memory-Interface. Hier reicht es, die Association Table entsprechend zu modifizieren.

sprich den entsprechenden Eintrag rauslöschen und die folgenden elemente eine position nach vorne schieben, dabei müsste man noch prüfen ob die entsprechende ga sonst nirgends mehr vorkommt und dann auch den Address Table in gleicher weise umschichten, sonst müllts den Address Table zu?

Irgendwie umständlich, schöner wärs wenn das die applikation selbst regelt aber dazu bräuchte es einen entsprechenden knx service mpropdelete oder so, den es aber nicht gibt oder?

Ich arbeite gerade an einem Java-Tool zur Konfiguration, dauert aber noch ein paar Tage. Das Gewürge mit mpropwrite & Co ist ja keinem normalen Menschen zuzumuten.

Da freu ich mich drauf, hab schon einiges an zeit verbraten weil ich mich vertippt hab mit den ganzen indizes usw. BTW, wie machst du das dort mit dem löschen der GAs?

[l0wside]

Damit wird aber im Address Table die Adresse 0/0/0 angelegt, nicht weiter schlimm aber der Association Table wird dann im verlauf der Zeit mit verweisen auf diese Adresse zugemüllt, oder hab ich einen denkfehler?

Im Moment hast du noch recht. Die Aufräumroutine, die alle hängenden Verweise in der Association Table rauswirft, fehlt noch.
Die Idee war wie folgt: direkter Zugriff über die mwrite-Funktionen, emulierter Zugriff auf die gleichen Werte über die Property-Funktionen. Bei Zugriff über das Property-Interface baut sich das Gerät dann aus den Angaben selbst die Association- und die Address-Table zusammen.

Leerstellen (d.h. Einträge mit 00) in einer der Tables sind ziemlich egal, kosten maximal ein paar µs Laufzeit. Beim nächsten Schreiben wird dann diese Stelle wieder aufgefüllt.

Das Config-Tool wird die Tabellen per Memory-Write direkt schreiben. Das Property-Interface ist eher was für die Kommandozeile.

Max

[tuxedo]

Ich habe noch nicht so recht verstanden, wo die Flags im Application Object genau gesetzt werden.

Und ich hab noch nicht verstanden wozu es bei den DIY Projekten die Flags überhaupt braucht?!

Kann mich mal jemand erleuchten?

Aktuell würde mein Projekt vorsehen dass ich Einstellungen habe (z.B. max. Helligkeitswert eines PWM Kanals des LED Controllers) und KOs (z.B. rel. dimmen Kanal A, akt. Helligkeitswert Kanal A) die einer GA zugeordnet werden können.

Was soll ich dann noch mit Flags? Verkompliziert das die Sache nicht etwas?

[l0wside]

Und ich hab noch nicht verstanden wozu es bei den DIY Projekten die Flags überhaupt braucht?!

Sie stehen nun mal im Standard, deswegen setze ich sie auch um.
Du kannst natürlich die Flags auch einfach hart verdrahten und fertig. Für Einzelstücke reicht das ja auch voll und ganz.

Max

[tuxedo]

Ah jetzt ja. Okay. Das ist ein Argument.

Ich bastle nebenher gerade an einer Alternative zu Robert's eibd-xpropwrite-Ansatz (in Bezug auf eibd, nicht jeder hat ein Linux und kann/will eibd aufsetzen). Wenn's was zu sehen gibt melde ich mich wieder.

[l0wside]

Ah jetzt ja. Okay. Das ist ein Argument.

Ich bastle nebenher gerade an einer Alternative zu Robert's eibd-xpropwrite-Ansatz (in Bezug auf eibd, nicht jeder hat ein Linux und kann/will eibd aufsetzen). Wenn's was zu sehen gibt melde ich mich wieder.

Ach so - ich hätte da was

http://www.kalassi.de/download/knxcfg.msi - ist nicht der aktuellste Stand, aber zum Anschauen reicht´s. Sourcecode (Qt-basiert) gerne auf Anfrage. Programm setzt auf Falcon auf (müsste automatisch mitinstalliert werden).

XML-Config-Datei zum Herumspielen unter http://www.kalassi.de/download/multisensor.xml.

Max

[tuxedo]

Ach so - ich hätte da was

http://www.kalassi.de/download/knxcfg.msi - ist nicht der aktuellste Stand, aber zum Anschauen reicht´s. Sourcecode (Qt-basiert) gerne auf Anfrage. Programm setzt auf Falcon auf (müsste automatisch mitinstalliert werden).

XML-Config-Datei zum Herumspielen unter http://www.kalassi.de/download/multisensor.xml.

Max

Danke, hab davon schon "gehört". Ich werd's mir anschauen.

Bin aber nicht so der Freund von Windows (habs nur im Büro) und bastle das dann eben "nochmal" mit Java und Calimero. Dann läuft's mit Windows, Linux, Mac und wenn ich mal ganz viel Zeit hab auch mit Android.
Aber für's erste ist die Kommandozeilen-Version dran.

Theoretisch funktioniert's schon. Hab nur mangels unpassender Arbeitsumgebung noch nicht am realen System testen können.

Dein XML-Format ähnelt meinem bisherigen sehr stark. Mal schauen ob ich das so übernehme.


[update]
Dein Tool lässt sich auf meinem Büro-PC nicht installieren:

"Kalassi Device Configuration Utility cannot be installed on Windows XP/Vista/Windows 7/Windows 8 x64/Windows 8.1 x64"

Ist eine Win7 64bit Maschine.


:-(