ARDUINO am KNX

[tuxedo]

So langsam fange ich an zu verstehen...
Ich sehe so langsam aber sicher woran man ein CONNECT von einem DISCONNECT Telegram unterscheiden kann.
Fällt mir aber noch etwas schwer zwischen den Interpretationsarten des Telegrams (Transport-Layer vs. Application-Layer) unterscheiden. Aber das krieg ich auch noch hin.
Aber ohne EIBA-Spec wäre das ganz schön heftig für mich.


[update]
Sodele... Den connect und disconnect kann ich nun erkennen. Ich hab nur noch kein Plan wie ich darauf reagieren muss.

[tuxedo]

So, nach 2 Tagen Entwicklung mal weitere Ergebnisse:

1) Die TPUART-Lib für den Arduino ist "sehr verstrickt". Es scheint, als ob der Urheber vom Protokoll und dessen Aufbau nur teilweise Kenntnis hatte.
2) Die CONNECT und DISCONNECT Telegramme werden schon behandelt. Aber mehr oder weniger "silently". Dauert ne Weile bis man das im Code entdeckt. Die Schwierigkeit daran: Wenn man die EIBA-Spec vor sich hat, dann sieht die Struktur darin ganz anders aus als in der Lib
3) PropertyRead-Requests kann ich nun annehmen, auswerten und theoretisch auch beantworten. Der Arduino ist fest der meinung er hat was geschickt, was aber nicht "acknowledged" wurde. Im Busmonitor in ETS sehe ich aber die Antwort nicht.

Ich dreh noch langsam hohl... beim bauen des Sketches (ich habs abgespeckt auf das minimalste, aber mit vielen Debug-Meldungen) sagt er mit schon dass ich 89% des Speichers (RAM) mit Variablen belegt hätte und dass es eng werden könnte.

Vermutlich wird es das auch, so dass wohl faktisch keine Antwort gesendet wird... ich kanns mir sonst nicht erklären.

Ich hab so langsam das gefühl dass ich für die Embedded-Entwicklung nicht gemacht bin. Ich bin so kurz (MitDemFingerZeig) davor das Teil hier http://www.acmesystems.it/arietta zu bestellen, nur damit ich "anständig entwickeln kann" ...

Dank WLAN würde ich mir den sperrigen Siemens BCU sparen, und hätte ein Linux auf dem ich (vermutlich) Problemlos mit Calimero und Java alles implementieren kann.

Erstmal raus an die frische Luft und auf andere Gedanken kommen... Dann sehen wir weiter.



[update]
Mühsam ernährt sich das Eichhörnchen. Es lag nicht am knappen Speicher. Ich hab dummerweise die gleiche Telegram-Referenz versucht zu modifizieren und dann zu senden. Das geht nicht. Es braucht eine andere Instanz. Eben nicht die, die gerade für den Empfang genutzt wurde.
Stimmt etwas an der Prüfsumme nicht, so verwirft der BCU das logischerweise.
Hatte eben ein kleines erfolgserlebnis: Die Prop-read Antwort wurde gesendet. Aber noch an eine falsche Addresse. Jetzt mit der richtigen scheint es wieder an der Prüfsumme zu hängen.

Stay tuned...

[sattler]

@tuxedo: Bitte nicht voreilig aufgeben. Ich hatte mir die arduinos schon zugelegt, komme aber aufgrund der anderen Sachen noch nicht zu, mir alles anzuschauen. Bzw. ich habe eine Bitte an dich: Wenn du schon aufgibst, bitte alles, was du bis jetzt erreicht hast irgendwie für die Nachwelt dokumentieren. Ich vermute, dass das, was du hier postest und irgendwo im Wiki ablegst nur 10%-20% an Informationen sind. Rest steckt leider in deinem Kopf. Wie gesagt, selbst wenn du aufgibst, wäre ich dankbar, wenn ich in ein Paar Wochen/Monaten auf dich zukommen dürfte, wenn ich Fragen habe.
Bzgl. WLAN und Funk allgemein. Es ist keine gute Lösung. Vor allem, wenn du dein Haus bereits voll verkabelt hast. Für Altbauten kann ich es ja noch einsehen, für Neubauten sollte man es nach Möglichkeit dort vermeiden, wo es geht und wo es nicht sinnvoll ist.
Bzgl. Java und Co. Du scheinst ja der neuen Generation der Programmierer anzugehören. Leider lernt man heute nicht mehr vernünftig mit C und sogar mit Assembler zu programieren. Ich gehöre noch zur Generation, wo man es vernünftig gelernt hat und wo man beim Programmieren an die Hardware und an die Ressourcen denkt. Von daher, ist noch nicht alles verloren. Du kannst es gerne mit Java und Co. versuchen, vernünftig ist es aber im Falle "embedded" nicht.

sattler

[tuxedo]

Servus Sattler,

nach dem kleinen Erfolgserlebnis von gestern hab ich die Flinte noch nicht ganz ins Korn geschmissen.
Ich habe auch n och C und Assembler "gelernt". Aber wenn man dann Jahrelang in einer Hochsprache entwickelt hat und dann auf einmal wieder begrenzt RAM und ROM zur Verfügung hat, die Entwicklungsumgebung "schwach" ist und man beim debuggen schon wieder ans Limit von RAM und ROM stößt, macht das einfach keinen Spaß.

Der Arietta G25 kann auch LAN (über USB-Adapter) und man könnte selbstverständlich auch den Siemens BCU dran hängen. was beim Ariette ohne weiteres gehen würde, was ich beim Arduino leider vermisse, sind Remote-Debugging-Fähigkeiten.

und wo man beim Programmieren an die Hardware und an die Ressourcen denkt.

Ich kenne beide Welten und nimm's mir nicht übel: Ich hasse es wenn Hochsprachen wie Java schnell nach "ressourcenfressend" und "da muss man nicht sonderlich drauf achten" verschrien sind. Die, die so mit Java entwickeln, sind genau die Leute, die den Ruf der Sprache schädigen. Egal welche Sprache man verwendet: Man muss wissen was man da mit den Ressourcen tut. Sonst ist es murks.

Du kannst es gerne mit Java und Co. versuchen, vernünftig ist es aber im Falle "embedded" nicht.

Wieso sollte Java da nicht vernünftig sein? Der Code ist super portabel, läuft auf nahezu jeder Plattform ohne extra Anpassungen oder Compilerflags, ist performant (jetzt komm mir nicht wieder mit der Leier von wegen "Java ist langsam". Denn dann hast du dich von den "keine Ahnung haben"-Entwicklern einlullen lassen).

Die einzigen Vorteile des Arduino sind:

* bootet schneller (ja, auch der Arduino-Bootloader will gestartet werden)
* keine Probleme mit Flashspeicher der mit den Jahren das zeitliche segnet

Bzgl. Doku: Selbstverständlich dokumentiere ich. Ist zwar für Dritte noch nicht wirklich zu gebrauchen (Doku ist nunmal zeitfressend wenn mans richtig macht), aber es ist ein Ansatz.

Gestern Abend bin ich noch soweit gekommen als dass ich eine Property-Antwort schicken kann. Aber nur an 0.0.0 ... Sobald ich eine andere Adresse angebe, geht das Telegram nicht auf den Bus... Hab noch kein Plan wieso. Muss da nun wieder solane im Dunkeln stochern bis auf auf die Ursache stoße. Weiter debuggen... ich wüsste nicht wie.

[sattler]

ok, verstanden!
Bzgl. Java. Nimm es mir bitte nicht übel. Ich bin kein SW-Entwickler eben, sondern komme eher von der Hardware-Welt. Und Programmieren lernt unser einer eher als Mittel zum Zweck. Wobei ich dir aus Erfahrung sagen muss, dass im echten Berufsleben die reinen Softwerker eher selten an das Programmieren der echten Hardware herangelassen werden. Ich hatte das zwar auch nicht geglaubt, es ist aber so. Man nimmt sich lieber einen Elektronikingenieur und bringt ihm bei, wie er programmieren kann, als einen fertigen SW-Experten von der Uni zu holen. Und wie man heutzutage Informatik an der Uni lehrt weiß ich auch aus näheren Erfahrung: Man beginnt mit Java an. Das sagt für mich schon alles. Ich will nicht Java schlecht reden und man kann sicherlich damit auch ressourcenoptimiert programmieren. Die Frage ist nur, wer macht das denn wirklich?
Bestes Beispiel: Bei uns auf der Arbeit laufen die meisten Applikationen in Java bzw. JavaScript. Abgesehen davon, dass du dafür nur IE nehmen muss und mit FF gar nichts läuft, bis das Zeug gestartet ist, vergehen Minuten. Man hätte alles auch schön in PHP und HTML schreiben können und es würde mindestens 10x schneller laden. Bloß, wo findest du einen Entwickler, der das noch vernünftig machen kann, wenn alle Unis nur diese "Java-Genies" herausbringen?
Auch für Embedded-Plattformen gibt es sicherlich gute Beispiele, wo es funktioniert. Die Masse der Entwickler macht es aber leider unvernünftig. Und daher entstehen solche Erfahrungen. Aber egal, ich glaube es dir schon, dass du es vernünftig machst!
Wie gesagt, ich würde gerne unterstützen, weil mich das Thema brennend interessiert, aber nicht jetzt. Derzeit kämfe ich noch mit der KNX-Grundinstallation. Wenn die halbwegs läuft, dann kommen die Addons, wozu auch Arduino gehört.

sattler

[tuxedo]

Achtung: Java != JavaScript. Bis auf das Wort "Java" im Namen haben die absolut nix miteinander zu tun.

[tuxedo]

Gestern der "Stress", heute die Erleuchtung:

Hab gestern den halben Sonntag damit verbracht das "seltsame Verhalten" meines IP-Routers in den Griff zu bekommen (und das bei fast 30° Sonnenschein...). Was war geschehen?
Nun, ich konnte mit der ETS noch den Gruppenmonitor benutzen, aber nichts mehr programmieren, und mein HS konnte auch nix mehr senden. Alles ohne weitere aufschlussreiche Fehlermeldung.
Ich war kurz davor die ganzen PAs über den Haufen zu werfen und neu zu programmieren, bis ich entdeckt habe, dass ich wohl am Samstag in einer nebensächlichen Aktion beim Entwickeln am Arduino die Applikation meines IP-Routers überbügelt und damit dessen Einstellung zurückgesetzt habe.
Dummerweise ist da per Default eingestellt: "Gruppentelegramme Hauptgruppe 0..13" --> "filtern". Das hatte zur Folge, dass hier tatsächlich gefiltert wurde, und zwar "ausgefiltert". Das ganze dann auf "weiterleiten" eingestellt und schon lief wieder alles. Irgendwie beruhigend dass es nicht am versagen von KNX sondern am versagen des Entwicklers lag...

Heute morgen beim Zähneputzen kam mir dann die Erleuchtung: Das wird sicherlich auf der Grund gewesen sein warum mein Arduino nur an 0.0.0 senden konnte und alles andere im Sand verlief.
Fazit: Heute Abend nochmal die Entwicklungsumgebung auspacken und weiter testen. Ich bin guter Dinge dass ich heute Abend die erste korrekte Antwort auf ein "PropertyRead" vom Arduino bekomme.

[update]
bzgl Debugging von Arduino-Code:
http://playground.arduino.cc/Code/VisualMicro ... Wenn's das für Linux gäbe ...Aber extra ein Windows aufsetzen mag ich dafür eigentlich nicht.

[tuxedo]

Neuer Tag, neues Glück. Ich berichte jetzt halt im Monolog wie es voran geht...

Es lag tatsächlich am IP-Router dass die Property-Antwort nicht ankam. jetzt antwortet der Arduino, aber Calimero schmeckt das noch nicht. Der Exception auf Calimero-Seite zufolge, sieht Calimero die verbindung nicht als "connected". Der witz ist aber: trotz nicht connected, wird schon mal nach der Property gefragt. Und die Antwort interessiert nicht, solange nicht connected ist?! Muss man das verstehen?
Egal, ich forsche weiter. Wenn jemand Daten zum mit-analysieren braucht: Siehe Anhang.



[update]

Wieder einmal kann ich nichts anderes als bilder anhängen. Hier der Download-Link.

http://denbh000.dyn.root1.de/public/...no/2015-06-15/

[tuxedo]

So, Ende des Tages...Bin wieder auf ein Problem gestoßen das ich aber calimero zuschreibe, weswegen ich bei den calimero-entwicklern mal nachgefragt habe was Sache ist: https://github.com/calimero-project/calimero/issues/22

Bin gespannt auf deren Antwort.

n8 ...


[update 16.06.2015]

Ich hab mir den Calimero-Source nochmal zu gemüte geführt und auch die Testcases mal angeschaut:

1) Es ergibt für mich keinen Sinn wieso Calimero seinen eigenen Connect-Request wieder empfängt und darauf mit einem Disconnect reagiert. Telegramme die an einen anderen Busteilnehmer gerichtet sind sollten Calimero doch nicht direkt interessieren, sondern nur Telegramme die an Calimero gehen? Hab diese Frage in obigem Link nochmal verdeutlicht. Mal schauen was kommt.

2) Die Testfälle zu Calimero decken auch Properties und Memory Read/Write Aktionen ab. Hab meinen Source mal mit dem Workflow in den Testfällen verglichen. Ist nahezu identisch. Werde da heute Abend nochmal mit experimentieren.

Alles in allem: Ich bin wohl nicht mehr weit von "der Prototyp funktioniert" entfernt.


[update]
Zumindest Teil 1) ist nun halbwegs gelöst bzw. geklärt: Der Multicast-Socket hat Loopback eingeschaltet. D.h. er bekommt alles was er selbst sendet wieder zugespielt. Kann man aber (mehr oder weniger aufwendig) abschalten. Es wurde vom Entwickler angemerkt dass dieses Default-Verhalten wohl nicht ideal ist. Habe angeregt das Default-Verhalten doch bitte zu ändern, oder zumindest dem Entwickler (ohne Reflection) es zu ermöglichen das Verhalten selbst zu ändern.

Zu 2) ... Muss ich noch klären. Vielleicht funktioniert die Sache nun schon wenn 1) gelöst ist ...

[tuxedo]

Erfolgserlebnis 2.0 ... *Yee-haw*

Mein Arduino konnte zum ersten mal ein Property-Read "beantworten" und Calimero hat nicht gemeckert.
Problemursache war:

Im 6. Byte des Telegrams wird an Bitposition 8+7 der Kommunikationstyp der Transportebene angegeben.
Der bisherige KNX Stack für den Arduino hat nur im Fall von NCD (nummerierte Steuerdaten) ein ACK geschickt (im Code nennt sich das "sendNCDPosConfirm").
Der Witz an der Sache: Der Methodenname ist stark irreführend. Denn es wird kein "PosConfirm" geschickt, sondern etwas, das sich in der EIBA Spec "T_DATA_ACk_PDU" nennt. Also ein Acknowledge für Daten auf Transportebene.
Und eine PropertyRead-Anfrage muss mit einem solchen ACK beantwortet werden. Nur kommt die Anfrage nicht als NCD, sondern als NDP (nummeriertes Datenpaket (was im EIBA-Jargon wiederum "T_DATA_REQ_PDU" heisst).

Ich seh den Wald bald vor lauter missverständluicher beschreibungen nicht mehr.
Ich werden jetzt die eine oder andere Methode mal umbenennen, dokumentieren und dann den Code aufräumen. Und dann wage ich mich an ein MemWrite ;-) Kann dann auch nicht mehr so schwer sein.
Wenn das rudimentär funktioniert, dann schieb ich die Änderung wieder zu Github hoch. Werde wohl einen Branch dafür anlegen, weil ich hab schon hier und da intern einiges ändern müssen.

P.S. Und noch was wichtiges:

Das Macro PA_INTEGER hat irgendwie manchmal eine Macke.

An manchen Code-Stellen eingesetzt, verhält sich der Code so, als ob die Methode in der das Macro eingesetzt wurde, gar nicht aufgerufen wird, aber ein Ergebnis zurückliefert... Sehr seltsam.
Bab nicht rausgefunden wieso das so ist. Aber statt des Macros kann man auch direkt das hier machen:

    byte target[2];
    target[0] = (area << 4) | line;
    target[1] = member;

und dann da wo man das Macro platziert hätte, einfach "target" einsetzen. Dann läuft der Code wieder.
Diese Erkenntniss hat mich STUNDEN gekostet. Vielleicht kann ja einer der Embedded-Kenner da was zu sagen?!

Zum Vergleich hier die Macro-Definition:

#define PA_INTEGER(area, line, member) (byte*)(const byte[]){(area << 4) | line, member}

[tuxedo]

So, nächstes Problem das im Umfeld MemWrite auftaucht:

Byte 6 und Byte 7 des Telegrams entscheiden, was es für eine Telegramnachricht ist.

Es gibt hierzu Enums im Arduino-Code, siehe https://bitbucket.org/dka/arduino-tp...m.h?at=default (der Originalcode)

Hier der entsprechende Abschnitt:

// KNX commands / APCI Coding
enum KnxCommandType {
KNX_COMMAND_READ = B0000,
KNX_COMMAND_WRITE = B0010,
KNX_COMMAND_ANSWER = B0001,
    KNX_COMMAND_INDIVIDUAL_ADDR_WRITE = B0011,
    KNX_COMMAND_INDIVIDUAL_ADDR_REQUEST = B0100,
    KNX_COMMAND_INDIVIDUAL_ADDR_RESPONSE = B0101,
    KNX_COMMAND_MASK_VERSION_READ = B1100,
    KNX_COMMAND_MASK_VERSION_RESPONSE = B1101,
    KNX_COMMAND_RESTART = B1110,
    KNX_COMMAND_ESCAPE = B1111
};

// Extended (escaped) KNX commands
enum KnxExtendedCommandType {
    KNX_EXT_COMMAND_AUTH_REQUEST = B010001,
    KNX_EXT_COMMAND_AUTH_RESPONSE = B010010
};

In der EIBA Spec steht "The application control field has a length of 4 or 10 bits, depending on the layer-7 service."
So ist das hier auch implementiert... KnxCommandType sind die ersten 4 Bits, und KnxExtendedCommandType sind die weiteren 6 Bits.

Bis dato hatte ich angenommen, dass die entsprechenden Bits in Byte 6 vom KnxCommandType auf "KNX_COMMAND_ESCAPE = B1111" passen, es sich um einen ExtendedCommand handelt und man noch die anderen 6 Bits hinzuziehen muss um an das tatsächliche Kommando zu kommen.

Quasi ein

IF commandtype == KNX_COMMAND_ESCAPE THEN
    // must be extended command, check also extendedcommandtype
FI

Aber so einfach ist es nicht. Zur Veranschaulichtung habe ich mal ein Bild hochgeladen (Octet 6+7):


Man sieht schön, dass es bei weitem nicht so ist, dass wenn die ersten 4 bit "1111" sind, es sich um ein "extended command" handelt.

Beispiel A_GroupValue_Write ... Damit schreibt man auf eine Gruppenaddresse. Blöd nur, dass Bit 6-1 von Octet 7 "leer" sind. Und leer ist hier nicht leer, sondern da stehen schon die Daten der Schreibaktion drinnen...


Wie also am besten mit diesen "Kraut und Rüben" umgehen?
Ich hab noch keine passende "Datenstruktur" gefunden die sich "einfach" nutzen lässt. Ich meine, es wäre einfach wenn es keine Lücken geben würde. Dann wäre der Commandtype eben immer 10 bit lang. Das würde sich einfach handhaben lassen.
Auch wäre es einfach, wenn die ersten 4 Bit immer einen ganzen Block bezeichnen würden. geht aber auch nicht, weil Group read/write/response sich schon in den ersten 4 bit unterscheiden...*argh*
Was haben die sich beim Protokolldesign nur dabei gedacht?

Any ideas wie man das am besten sauber abbildet? Es muss nicht _jeder_ CommandType aus der obigen Abbildung drauf passen. Aber das wichtigste sollte schon reinpassen 8group read/write/response, property read/write/response, memory read/write/response, PhysicalAddress read/write/response, authorize request/response und so Dinge eben...)

Werde nun parallel bei Calimero schauen ob ich da ein Muster übernehmen kann.

Ansonsten wird mir wohl nix anderes übrigbleiben als eine ziemlich große Methode zu bauen die die notwendigen Fälle voneinander unterscheidet und das dann in ein einzelnen Enum-Wert formt den man dann später per switch/case oder if handhaben kann.



[update]
Bis uns was besseres einfällt hab ich's jetzt mal so gelöst. Denke das ist noch übersichtlich/wartbar und geht vom Speicherbedarf im Arduino noch:

enum ApplicationControlField {

    A_UNKNOWN = 0,

    A_GROUPVALUE_READ           = 1,
    A_GROUPVALUE_RESPONSE       = 2,
    A_GROUPVALUE_WRITE          = 3,
    
    A_PHYSICALADDRESS_READ      = 4,
    A_PHYSICALADDRESS_RESPONSE  = 5,
    A_PHYSICALADDRESS_WRITE     = 6,
    
    A_PROPERTYVALUE_READ        = 7,
    A_PROPERTYVALUE_RESPONSE    = 8,
    A_PROPERTYVALUE_WRITE       = 9,
    
    A_MEMORY_READ               = 10,
    A_MEMORY_RESPONSE           = 11,
    A_MEMORY_WRITE              = 12,
    
    A_DEVICEDESCRIPTOR_READ     = 13,
    A_DEVICEDESCRIPTOR_RESPONSE = 14,
    
    A_RESTART                   = 15,
    
    A_AUTHORIZE_REQUEST         = 16,
    A_AUTHORIZE_RESPONSE        = 17    
    
};


........



ApplicationControlField KnxTelegram::getApplicationControlField() {

    ApplicationControlField result = A_UNKNOWN;

    // first four bits: octet 6 bit 1+2 PLUS octet 7 bit 7+8
    int bits4 = ((buffer[6] & B00000011) << 2) | ((buffer[7] & B11000000) >> 6);
    // following 6 bits: octet 7 bit 1-7
    int bits6 = (buffer[7] & B00111111);

    switch (bits4) {

        // GROUP
        case B0000:    
            result = A_GROUPVALUE_READ;
            break;
        case B0001:
            result = A_GROUPVALUE_RESPONSE;
            break;
        case B0010:
            result = A_GROUPVALUE_WRITE;
            break;
            
        // PHYSICAL
        case B0011:
            if (bits6 == B000000) result = A_PHYSICALADDRESS_WRITE;
            break;
        case B0100:
            if (bits6 == B000000) result = A_PHYSICALADDRESS_READ;
            break;
        case B0101:
            if (bits6 == B000000) result = A_PHYSICALADDRESS_RESPONSE;
            break;
            
        // PROPERTY    
        case B1111:
            if (bits6 == B010101) result = A_PROPERTYVALUE_READ;
            else
            if (bits6 == B010110) result = A_PROPERTYVALUE_RESPONSE;
            else
            if (bits6 == B010111) result = A_PROPERTYVALUE_WRITE;
            break;
            
        // MEMORY    
        case B1000:
            if ((bits6 & B110000) == B00) result = A_MEMORY_READ;
            break;            
        case B1001:
            if ((bits6 & B110000) == B00) result = A_MEMORY_RESPONSE;
            break;            
        case B1010:
            if ((bits6 & B110000) == B00) result = A_MEMORY_WRITE;
            break;            

        // DEVICE DESCRIPTOR    
        case B1100:
            if (bits6 == B000000) result = A_DEVICEDESCRIPTOR_READ;
            break;
        case B1101:
            if (bits6 == B000000) result = A_DEVICEDESCRIPTOR_RESPONSE;
            break;
            
        // RESTART    
        case B1110:
            if (bits6 == B000000) result = A_RESTART;
            
    return result;
}

Damit kann man dann das Telegramm ganz einfach nach seinem Typ (ApplicationControlField) fragen und auf das Ergebnis dann mit einem Switch-Case sauber eine für die Anwendung relevante Fallunterscheidung machen.

Muss den Code allerdings noch ausprobieren.

[tuxedo]

Es ist vollbracht:

Ich kann von Java aus den Arduino mit memwrite und memread befeuern. Funktioniert. hab die obige Struktur noch etwas anpassen müssen, aber es funktioniert.
PropertyRead geht ebenso. PropertyWrite folgt dann bei bedarf noch. Damit ist der Weg frei für das Konfigurationstool (das in weiten Teilen schon fertig ist, aber auch nich viel feinschliff braucht).

Was noch fehlt sind ggf. Sicherheitsmechanismen. Man kann sich z.b. über einen Key erst am KNX Gerät authentifizieren bevor dieses den Zugriff erlaubt. Aber das sind "Details". Der Arduino hat typischerweise nur 1k EEPROM. Man kann aber über memread/memwrite bis 64k addressieren. Da fehlt noch der Sicherheitscheck etc.

Wichtig ist, dass die Basis geschaffen ist um das Ding "irgendwie" programmieren zu können.
Ist heute schon spät. Räume den Code dann morgen erst auf.
Was noch zu tu ist: den Code von den alten "KnxCommandType" und "KnxExtendedCommandType" Fragmenten säubern. Da muss dann noch einiges an kosmetischen Eingriffen erfolgen.

Liest hier eigentlich noch jemand mit, oder bin ich im Monolog gefangen, weil "zu komplex"? Wäre super wenn sich da noch jemand anderes zeitnah "hindurchquält", damit ich einen Mitstreiter habe.

[update]
Hab meinen Entwicklungsstand nach einigen Kämpfen mit git zu Github hoch geschoben (muss nach Jahren mit SVN erstmal den Git-Workflow verinnerlichen). Hab dafür einen extra Branch angelegt: https://github.com/KNX-on-Arduino/Kn...elop_knxdevice
Darin werde ich die Änderungen weiter pflegen und bei fertigstellung dann in den Hauptzweig mergen. Aber zuvor sollte da jemand mal drüber schauen und seine Meinung kund tun.

[sattler]

@tuxedo: Ich lese ab und zu mit, verstehe aber nur Bahnhof, wenn ich ehrlich bin. Ich weiß in etwa, wofür du kämpfst, die Details nachzuvollziehen ist aber sehr schwer, wenn man sich nicht in die Thematik vollständig einliest. Und dafür habe ich momentan keine Zeit. Destotrotz ist wichtig, dass du hier über deine Erfolge und Misserfolge mitblogst.

sattler

[tuxedo]

Ein weiterer kleiner Erfolg:

Ich habe in den letzten 4 Stunden das Kommandozeilentool zum programmieren des Arduinos soweit angepasst/umgebaut, dass das XML-Format das ich hier zuletzt beschrieben hatte geparst wird und die Daten bzw. der Konfiguration zum Arduino geschrieben wird.
Den Übergang zum Arduino muss ich nochmal etwas überarbeiten. Sollte aber in 1-2h erledigt sein (heute nicht mehr, morgen wieder).

Nächster Schritt ist dass das grafische Frontend für das Kommandozeilentool. Hab da auch schon einiges vorbereitet. Könnte ne halbe Woche bis Woche brauchen bis das dann auch zum ersten mal läuft.

Ich halte euch auf dem laufenden.

JuMi2006
Wie läufts mit deinen Basteleien? Fortschritte? Oder Wetter zu gut zum basteln?

[tuxedo]

Hab das Kommandozeilentool mal etwas ausgeräumt und eingecheckt: https://github.com/KNX-on-Arduino/KarduinoConfig

Muss aber noch "hübsch" gemacht und vor allem getestet werden.