ARDUINO am KNX

[tuxedo]

Hab nochmal am Backend gearbeitet:

Mein SlicKnx hat jetzt eine KarduinoManagement-Klasse erhalten, mit der sich der Arduino managen lässt:

* readMem
* writeMem
* restart
* writeAddress
* readAddress
* authorize

Letzteres wird ggf. ein nettes Gimmick: Man kann im Arduino einen 4-byte langen Key hinterlegen. Wenn man dann auf den Speicher des Arduinos zugreifen will, dann muss man sich vorher mit dem passenden Key authentifizieren.

Ob man das braucht? Keine Ahnung. Wohl eher nicht. Ist aber implementiert.

Nächster Schritt ist dann die Anbindung an die grafische Oberfläche.

[tuxedo]

Das Gegenstück hab ich in einen speziellen Branch gesteckt. Muss noch hübsch gemacht und in den Master-Branch gemerged werden. Aber ja: Ein funktionierendes Gegenstück gibt es schon.

[mode]

Da kann man nur sagen....

Leider geil!

Super Leistung, gefällt mir. Das Gegenstück zu deiner Konfigsoftware ist nun schon Teil des KNX Stacks?

[tuxedo]

So, es gibt nochmal mehr zu sehen:

Hab das Frontend jetzt so weit "bedienbar" bekommen, dass man "bequem" PA, Gruppenadressen und die Geräteparameter konfigurieren kann.
Das XML Format lässt sich also schon lesen...
Was noch fehlt:
* Einstellungen wieder in die XML zurückschreiben (eine extra DB wie in ETS wird's hier erstmal nicht geben). Hat den Vorteil dass man die Konfiguration jemandem mal zuspielen kann, oder auch direkt in der Konsole oder mit einem Texteditor mal anpassen kann.
* Anflanschen der bereits funktionierenden Programmier-Schnittstelle. Getrenntes und kombiniertes PA <-> GA/Parameter programmieren. Mehrere Geräte gleichzeitig programmieren...

Könnte tatsächlich im laufe der kommenden Woche fertig werden.

Vorgehensweise: Beim programmstart öffnet man ein "Projektverzeichnis". Das ist ein x-beliebiges Verzeichnis in dem sich die betreffenden XML-Dateien aufhalten.
Alle XML darin werden dann eingelesen und die Geräte entsprechend aufgelistet.
Man kann das Gerät benennen und eine PA vergeben.
Bei den KOs kann man ebenfalls eine Beschreibung sowie eine GA vergeben. Die restlichen Spalten dienen nur der Information.
Die Parameter lassen sich Gruppieren (siehe XML Format). Verschachtelte Gruppen gibt's nicht. Man selektiert die Gruppe und bekommt die zugehörigen Parameter angezeigt.
Wie wie Textfelder und Drop-Down Boxen gibt's nicht. Eine Eingabevalidierung findet hier noch nicht statt. Kann aber später noch realisiert werden. Bei den DropDown Boxen werden vorgefertigte Werte mit sprechenden Namen zur Auswahl gestellt.
Ein "wenn ich hier A eingestellt habe, taucht eine Gruppe B auf" wie man es von der ETS kennt gibts (noch) nicht.

Die Anwendung braucht aktuell Java8 (könnte man ggf. auf java7 runterschreiben wenns nötig wird) und sollte auf allen Plattformen (Win, Linux, Mac, je 32 und 64bit) laufen. Angedacht habe ich ein "fix und fertig-Paket": Eine ZIP inklusive allem. Auspacken, auf die Platte legen und starten. Keine Java-Installation notwendig (dafür ist die ZIP dann etwas größer, weil Java mit drin...)

Das Look'n'Feel der Anwendung habe ich mal fix eingestellt. D.h. sieht auf allen Plattformen (bis auf die äußere Fensterdekoration) exakt so aus wie im Screenshot. Kann ich aber bei Bedarf beliebig ändern (u.a. "Plattform-L'n'F"). Fand das L'n'F aber ganz "stylisch".

Code ist übrigens bei Github verfügbar.

So, ich hau mich dann auf's Ohr... n8...

Und hier nun die Screenshots:

Bildschirmfoto - 19.06.2015 - 23:49:24.png Bildschirmfoto - 19.06.2015 - 23:47:22.png Bildschirmfoto - 19.06.2015 - 23:48:04.png Bildschirmfoto - 19.06.2015 - 23:48:42.png

[tuxedo]

Bei deinem Tempo kann ich nicht mithalten . Beruf, Haus und 2 Kinder ...

Hab bis auf die Anzahl der Kinder (bisher 1 statt 2) die gleichen Randbedingungen. Hab die letzten Tage die arbeiten "in die Nacht" verlegt: Die Frau schaut Frauenfußball und ist beschäftigt (und meckert nicht), und ich kann entwickeln ;-)

Hier mal ein Screenshot der grafischen Frontends:

Unbenannt.PNG

Ist noch micht fertig, sieht aber schon hübsch aus. Vor allem hängt's noch am Parameter-Tab. Das ist noch nicht so toll zu verwenden. Denke in einer Woche oder so könnte ich eine testbare Version fertig haben.

[JuMi2006]

Ich arbeite immer mal wieder an dem kleinen bisschen Hardware. Habe aber durch die Spiegelung des Boards vergessen ein paar Pins zu tauschen . Beruflich ist hier momentan leider auch nicht viel zu reissen und nebenbei noch ein paar andere Projekte. Ich denke im Juli komme ich mal ein wenig intensiver dazu, vorher sehe ich da kaum Luft.
Bei deinem Tempo kann ich nicht mithalten . Beruf, Haus und 2 Kinder ...

[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.

[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?

[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]

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.

[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]

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, 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]

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]

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.