ARDUINO am KNX

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

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.

[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

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

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.

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

Hab heute weiter am Backend geschraubt: Grund:

read/write mem alleine reicht nicht. Es wäre ja nicht verkehrt zu wissen (und zwar bevor man seinen Arduino mit dem Tool programmiert), ob Hardware/Firmware auch zur Konfiguration passen.
Also bin ich dabei die eine oder andere Property fest (aber einstellbar) einzubauen.

Dabei bin ich - wie sollte es auch ander sein - wieder auf einen hässlichen Bug gestoßen:

Telegramme wie "PropertyvalueRead" die vom PC an den Arduino gehen, müssen mit einem "T_ACK" quittiert werden.
Die Anfrage vom PC enthält eine Sequenz-Nummer. Und die T_ACK Nachricht muss die gleiche inne haben.

Folgendes Testszenario spiele ich gerade durch:

1) Verbinden
2) Eine beliebige Property abfragen
3) Trennen
4) Verbinden
5) Speicher schreiben
6) Speicher lesen
7) Trennen

Probleme macht Punkt 6...

In diesem verbindungsteil sind zwei Aktionen. Und Punkt 6 ist die zweite Aktion. Demnach hat sich hier die Seqzenz-Nr. von 0 auf 1 inkrementiert.
Die T_ACK Nachricht sollte also die SeqNr 1 haben.

Aber im Busmonitor sehe ich das hier:

Bildschirmfoto - 23.06.2015 - 16:23:53.png


Eintrag Nr. 15 zeigt das Problem: Es wird ein T_ACK mit SeqNr 0 gesendet. Und auch nicht nur 1x, sondern 2x, gefolgt von einem eigentlich richtigen T_ACK mit SeqNr. 1 ..

Ich debugge seit Stunden. Immerhin bin ich jetzt auf dem Pfad dass Calimero wohl nicht die Fehlerquelle ist, sondern der Arduino.
Zur Ablenkung zwischendurch hab ich mal ein "besseres" Logo gebastelt:

KARDUINO-Logo.png

Hab mich etwas vom KNX Logo und dem Arduino-Logo bzw. dessen Schriftzug inspirieren lassen. Hoffe das ist "weit genug" von "Verwechslungsgefahr mit KNX und Arduino" entfernt. Sieht ja auch etwas "krakelig" aus. Aber das ist absicht. Ist ja auch ein Bastelprojekt. Gebastelte Schaltung -> Gebasteltes Logo ;-)

Gegenvorschläge?



[update]

Monologe sind doch was tolles ;-)

Gelöst hab ich das Problem noch nicht. Aber ich habe eine der Ursachen gefunden:

Wenn der TPUart dem Arduino ein Telegramm schickt, dann muss der Arduino binnen 1,7 Millisekunden antworten und sagen ob das Telegramm für ihn bestimmt ist oder nicht.

Wenn man vor diesem ACK Debug-Ausgaben etc. hat, dann kostet das u.U. zu viel zeit und das ACK kommt nicht rechtzeitig am TPUart an.
Man man man. Entweder bin ich so "Groß-PC" verwöhnt, oder ich muss jetzt tatsächlich um Millisekunden feilschen.

Bin nun leider an einer Stelle angelangt wo ich ohne Änderung am Code, rein durch mehrfaches ausführen, zu einem unterschiedlichen Ergebnis komme. Das macht die Analyse leider nicht einfach.

[lio123]

"Monologe sind doch was tolles ;-)"

oute mich mal als stiller Mitleser-auch wenn ich nicht alles verstehe, klingt das sehr interessant und es kommt anscheinend etwas ganz Brauchbares dabei raus!

Weiter so - ich melde mich wieder, wenn ich wissen möchte was man damit alles machen könnte


Grüße,
Lio

[tuxedo]

Nicht nur Monologe sind was tolles. Nein, auch die Embedded-Entwicklung ist toll... Da kommt's auf 1,7 Millisekunden an. "Hää? Wie, wo, was?"

Ich habe mich gestern noch gewundert, warum die Sache mit dem ACK so durcheinander kommt. Das lag wohl an meinen vielen Debug-Ausgaben auf der seriellen Schnittstelle. Irgendwann hab ich in der TPUart-Doku gelesen:

The U_AckInformation-Service is to indicate if the device is addressed. This service must be send latest 1,7 ms (9600 Baud) after receiving the address type octet of an addressed frame.

Zu deutsch: Wenn der TPUart am dem Arduino ein Telegramm weiterreicht, dann muss der Arduino binnen 1,7ms dem TPUart bescheid sagen ob das Telegramm für ihn relevant ist oder nicht. Und das muss über dieses Acknowledge geschehen.
Wenn man nun zu viel Debug-Informationen ausgibt während man das ankommende Telegramm parst, dann sind da schnell mal 1,7ms vergangen. So zumindest meine Vermutung.

Nun, sämtliche Debug-Ausgaben bis zum Senden des ACk entfernt, und schon sieht die Welt anders aus. Aber funktionieren tut's noch immer nicht. Wenn ich zwischen einem verbindungsabbau und einem verbindungsaufbau (also zwischen 3) und 4)) auf Java-Seite ein kleines Delay einbaue (300ms reichen), dann wird die Sache nochmal besser. Das ACK kommt mit der richtigen Sequenz an, aber Java quittiert den MemRead-Response mit einem N_ACK... Es scheint so, als würde Calimero hier eine falsche Sequenz-Nr. sehen, obwohl der ETS Busmonitor nun alles korrekt dastehen lässt.

Meine Geduld wird wieder einmal auf die Probe gestellt.

Was ich auch nicht verstehe:

Das Delay habe ich zwischen Schritt 3 und 4 eingebaut, wirkt sich aber auf Schritt 6 aus... Ein Delay an anderer Stelle ist nicht relevant.
Und es kommt noch besser: vertausche ich in der Reihenfolge 5 und 6, so klappt alles fehlerfrei?! Dabei sollte es doch egal sein ob ich nun erst schreibe und dann lese oder umgekehrt.

Ich debugge weiter...


[update]

Wenn ich auf PC Seite ruhoger angehen lasse und zwischen jedem Telegramm 300ms Delay einbaue, dann klappt die Sache schon erheblich besser. Ehrlich gesagt stochere ich momentan mal wieder nur im dunkeln. Aber mangels Ideen ist das erstmal besser als nix.
Ich hab nun auch ein Retry eingebaut: Geht ein Lese-versuch seitens Java schief, wird kurz gewartet und einfach nochmal probiert. Das macht Calimero sonst auch so.
Mein Testszenario ist nun etwas anders: ich versuche x-mal nacheinander die gleiche Aktion zu triggern. Bei 300ms Delay zwischen den Aktionen bin ich nun bei mehr oder weniger konstant 10 Erfolgen, gefolgt von einem Fehlversuch angelangt. Und der klappt auch nach 3x probieren nicht. Der Arduino zeigt mir, dass der TPUart das vom Arduino gesendete Antwort-Telegram offenbar nicht annimmt.
Wenn ich jetzt noch wüsste warum?!

[EPIX]

ich bewundere deine Beharrlichkeit - es klingt spannend...
Besonders beachtlich finde ich wie weit du schon gekommen bist!!

[tuxedo]

Danke für die aufmunternden Worte. Glücklicherweise habe ich diese Woche Zeit und offenbar auch ausreichend Elan um dran zu bleiben.

Gerade eben wieder ein wunderschönes Beispiel für "Code ohne Debug verhält sich anders als mit Debug" gehabt:

Wenn ich vor dem zurücksenden des MemReadResponse auf Arduino-Seite das telegramm auf der Debug-Console ausgeben lasse, sind auf einmal viele Fehler verschwunden. Und was heisst das? Timing-Problem

Bin glaub nicht sonderlich gut darin das sauber in den Griff zu bekommen. Aktuell behelfe ich mir damit, dass ich vor dem Senden des MemReadResponse einfach 300ms auf Arduino-Seite schlafe (fix 30ms Delay), und auf Calimero-Seite sicherstelle, dass zwischen zwei Telegramm-Sendungen nicht weniger wie 150ms Zeit liegen (ein kalkuliertes Delay).

Aber so richtig toll ist das mit dem Delay ja auch nicht.

Ausgehend von 150ms Delay auf Calimero-Seite:
100x MemWrite mit je 10 byte: Dauert 32sek bei ~18% durchschnittlicher Buslast
---> Läuft mehrfach ohne einen einzigen Fehler. Je niedriger ich das Delay ansetze, desto wahrscheinlicher der Fehlerfall. 150ms scheinen okay zu sein.

Wieder 150ms auf Calimero-Seite, aber 30ms vor der Response-Antwort auf Arduino-Seite:
100x MemRead für je 10 byte: Dauert 65 bis 93sek bei ~20-25% durchschnittlicher Buslast
--> Läuft immer mal wieder ein einen Timeout. Fehlerrate, aber durch Retries noch abgefangen, liegt bei ca. 5-10% (5-10 von 100 MemRead brauchen einen Retry).

In der Praxis wird man auf einen kleinen Arduino wohl eher weniger 1kbyte an Daten Schicken oder von ihm lesen müssen. Von daher sollte das nicht "tragisch" sein. Aber meine Entwickler-Ehre lässt das eigentlich nicht zu. Das muss besser werden.

Ich mache noch ein paar Tests und dann wandert der aktuelle Entwicklungsstand wieder zu Github.

[division]

Hallo,

ich versuche mich gerade auch an den ersten Schritten mit einem Arduino. Dank der bemerkenswerten Leistung hier klappt es auch recht einfach auf den Bus zu senden.

Ein Blinklich an der Bürodecke ist kein Problem.

Leider klappt das empfangen und reagieren auf KNX Telegramme überhaupt nicht.

Mein Setup ist der Siemens Busankoppler und ein Arduino Uno R3.
Diese sind wie im ersten Post beschrieben mit einander verbunden.

Ich habe in jedem if des serialEvent() ein digitalWrite(led, HIGH); um zu sehen ob das ganze wenigsten irgendwann mal aufgerufen wird.... Aber es sieht so aus als ob
SerialEvent() niemals durchlaufen wird.

Leider ist man mit dem Uno wegen der einen Seriellen Schnittstelle sehr eingeschränkt was das debuggen angeht.

Jemand eine Idee was ich flasch mache?

Ich versuche das mit diesem Code:

#include <KnxTpUart.h>

KnxTpUart knx(&Serial, "0.0.211");
int led = 13;

void setup() {
    Serial.begin(19200);
    UCSR0C = UCSR0C | B00100000;
    knx.uartReset();
    knx.addListenGroupAddress("0/0/14");

    pinMode(led, OUTPUT);
    digitalWrite(led, LOW);
}


void loop() {
    //knx.groupWriteBool("0/0/14", true);
    //digitalWrite(led, HIGH);   
    //delay(1000);
    //knx.groupWriteBool("0/0/14", false);
    //digitalWrite(led, LOW);    
    //delay(1000);             
}


void serialEvent() {
    KnxTpUartSerialEventType eType = knx.serialEvent();
    if (eType == TPUART_RESET_INDICATION) {
        digitalWrite(led, HIGH);
    }
    
    else if (eType == UNKNOWN) {
        digitalWrite(led, HIGH);
    }
    
    else if (eType == KNX_TELEGRAM) {
        KnxTelegram* telegram = knx.getReceivedTelegram();

        if (telegram->getFirstDataByte() == 0) {
            digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
        }
        else {
            digitalWrite(led, LOW);   // turn the LED on (HIGH is the voltage level)
        }
    }

}

Hoffentlich kann mir jemand helfen.....

Viele Grüße

Jan

[tuxedo]

Es gibt für Arduino eine SoftSerial Lib. Mit der kannst du zwei Digital-IO Pins zur seriellen Schnittstelle machen. Damit kannst du wieder parallel auf die Console debuggen.

Dein Code ist nicht vollständig was den Empfang einer Gruppenadresse anbelangt. Aktuell nimmst du _jedes_ Telegramm und schaltes in Abhängigkeit vom ersten Datenbyte.

Du musst/solltest auswerten ob es das passende Telegramm ist. Hier mal ein Stückchen Beispielcode, ungetestet und nur schnell zusammenkopiert (weiß ja nicht welche Lib-Version du gerade verwendest):

KnxTelegram* telegram = knx.getReceivedTelegram();

// Check which kind of telegram it is
switch(telegram->getCommand()) {

    // someone is sending data (to us?)
    case KNX_COMMAND_WRITE: 
        byte ga[2];
        telegram->getTarget(ga);
        
        if (ga == _gaSwitch) {
            state = telegram->getBool();
            digitalWrite(led, state);
        }
        break;
        
    default:
        break;
}

[division]

Hallo und vielen Dank für deine Antwort.

Ich habe es mal ganz einfach gemacht.....

void serialEvent() {
 digitalWrite(led, HIGH);
}

Selbst das wird nie mal aufgerufen. Ich komme also garnicht bis dahin, etwas Sinnvolles zu machen.
Weiter vorne auf Seite 29 oder so im Thread hatte ein anderer User hier GENAU das gleiche Problem.
Uno geht nur senden....
Leonardo angesteckt mit gleichem Code...
alles wunderbar.
Also irgendwie hat das schon mit der Seriellen Schnittstelle vom Uno zu tun. Er hat sich damals laut dem Thread hier einfach den Leonardo oder Mega gekauft und fertig. Aber das kann ja nicht die Lösung sein. Kann ich dann die KNX Library auch auf den Software Serial mit den Digitalpins initialisieren? Oder ist die dann nur für debugging?

Viele Grüße Jan

[tuxedo]

KNX auf der soft-serial würde ich lassen. Wenn dann das debugging auf der soft-serial.

Hast du mal nach einem Code-Beispiel (ohne KNX) gesucht das die serielle Schnittstelle des Uno verwendet? Sofern das nicht sauber funktioniert, brauchst du mit KNX nicht anfangen.

Im übrigen: Einen Arduino Leonardo (groß) oder Micro (passt in eine UP-Dose) bekommst du für ~7EUR ...