ARDUINO am KNX

[tuxedo]

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

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

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]

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

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

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

Hat schon mal jemand erfolgreich die KNX-Lib über ein Software-Serial laufen lassen?

[tuxedo]

Bin dabei die Lib zu Testzwecken etwas auszublasen damit ich mal verstehe was der TPUART von sich gibt wenn ich auf der anderen Seite mit Calimero versuche Daten zu schreiben. Der "CONNECT" ist immer noch "sagenumwoben" und im Arduino-Code noch gar nicht "aufgetaucht", weshalb wohl auch so ziemlich alles fehl schlägt was über die "verbindungslose" Multicast-Verbindung eine "tatsächliche" P2P-Verbindung braucht.

Liest hier vielleicht jemand mit der sich mit dem TPUART-Protokoll auskennt und kann was zum Programmiervorgang memwrite/memread bzw. propwrite/propread sagen?

P.S. Die letzte genannte Lib kann das auch nicht. Die ist nur etwas "hübscher" implementiert. Aber dort ist ebenfalls alles hardcodiert.

[tuxedo]

Vielleicht sollte man sich mal das hier genauer anschauen??
https://github.com/franckmarini/KnxDevice

Vllt. ist das Problem ja hier schon gelöst.

[tuxedo]

Ich komm nicht weiter .....

Wenn ich mit Calimero ein ein MemWrite mache, dann will er zuerst eine Property abfragen.
Also hab ich mich jetzt mal auf die Property-geschichte konzentriert.

Was ich im Busmonitor ud im Source von Calimero sehen kann ist, dass zuerste ein "connect" stattfindet. Den will Calimero zuerst beantwortet haben bevor es mit dem PropertyRead-request weiter geht. Aber das geht schief. Nämlich weil der Arduino die Connect-Anfrage nicht kennt und beantwortet.

Dummerweise werden die Connect-telegramme als grouWrite Telegramme erkannt?!

Hier mal der Vergleich zwischen einem Connect und einem tatsächlichen GroupWrite:

Connect:

Processing ...
--> KNX command write
buffer[0] hex=B0     bin=10110000
buffer[1] hex=FF     bin=11111111
buffer[2] hex=1     bin=1
buffer[3] hex=FF     bin=11111111
buffer[4] hex=14     bin=10100
buffer[5] hex=50     bin=1010000
buffer[6] hex=80     bin=10000000
buffer[7] hex=8A     bin=10001010
buffer[8] hex=3     bin=11
buffer[9] hex=44     bin=1000100
buffer[10] hex=BC     bin=10111100
buffer[11] hex=0     bin=0
buffer[12] hex=0     bin=0
buffer[13] hex=0     bin=0
buffer[14] hex=0     bin=0
buffer[15] hex=0     bin=0
buffer[16] hex=0     bin=0
buffer[17] hex=0     bin=0
buffer[18] hex=0     bin=0
buffer[19] hex=0     bin=0
buffer[20] hex=0     bin=0
buffer[21] hex=0     bin=0
buffer[22] hex=0     bin=0
Repeated: 0
Priority: 0
Source: 15.15.1
Target Physical: 15.15.20
Control Data: bin=0
Routing Counter: 5
Payload Length: 1
Command: hex=2 bin=10
First Data Byte  hex=A    bin=1010
Checksum matches
Processing ... *DONE*

GroupWrite:

Processing ...
--> KNX command write
buffer[0] hex=BC     bin=10111100
buffer[1] hex=11     bin=10001
buffer[2] hex=0     bin=0
buffer[3] hex=3F     bin=111111
buffer[4] hex=7     bin=111
buffer[5] hex=F2     bin=11110010
buffer[6] hex=0     bin=0
buffer[7] hex=80     bin=10000000
buffer[8] hex=FF     bin=11111111
buffer[9] hex=E7     bin=11100111
buffer[10] hex=DD     bin=11011101
buffer[11] hex=0     bin=0
buffer[12] hex=0     bin=0
buffer[13] hex=0     bin=0
buffer[14] hex=0     bin=0
buffer[15] hex=0     bin=0
buffer[16] hex=0     bin=0
buffer[17] hex=0     bin=0
buffer[18] hex=0     bin=0
buffer[19] hex=0     bin=0
buffer[20] hex=0     bin=0
buffer[21] hex=0     bin=0
buffer[22] hex=0     bin=0
Repeated: 0
Priority: 3
Source: 1.1.0
Target Group: 7/7/7
Control Data: bin=0
Routing Counter: 7
Payload Length: 3
Command: hex=2 bin=10
First Data Byte  hex=0    bin=0
Data Byte 2      hex=FF    bin=11111111
Checksum matches
Processing ... *DONE*

Ich hab extra mal in beiden Fälle den kompletten buffer-Inhalt mit ausgeben lassen.
Aber ich seh den Unterschied nicht...

Bisher habe ich mich an folgender Protokolldoku entlang gehangelt: http://www.mikrocontroller.net/attac...schreibung.pdf

Aber ich komme auf keinen grünen Zweig. Im Arduino-Code ist in Telegram.h schon ein Enum für den Connect vorgesehen:

// KNX Control Data (for UCD / NCD packets)
enum KnxControlDataType {
    KNX_CONTROLDATA_CONNECT = B00,      // UCD
    KNX_CONTROLDATA_DISCONNECT = B01,   // UCD
    KNX_CONTROLDATA_POS_CONFIRM = B10,  // NCD
    KNX_CONTROLDATA_NEG_CONFIRM = B11   // NCD
};

Aber speziell der Connect-Typ findet keine Anwendung. Der Enum an sich wird zusammen mit buffer[6] benutzt:

KnxControlDataType KnxTelegram::getControlData() {
    return (KnxControlDataType) (buffer[6] & B00000011);
}

Also die rechten zwei Bits. Hab mir das aus ausgeben lassen (siehe im Log die Zeile "Control Data", Angabe ist binärer String).

In beiden Fällen (connect/groupwrite) ist das B00 ...

Das verwirrende: Laut Code sind es die rechten zwei Bits aus buffer[6]. Laut oben genannter Doku ist buffer[6] aber das "Byte 6" und dessen rechten zwei Bits aber Teil des entsprechenden Kommandos?!?!? (vgl. Doku Seite 9 / Abschnitt 2.5.1)

Selbst wenn ich dann raus gefunden habe wo sich die beiden Nachrichten voneinander wie abgrenzen: Ich hab noch kein Plan wie die Connect-Antwort auszusehen hat.

Der Calimero Code ist zwar toll, aber so aufgeblasen und über viele Klassen verteilt, dass ich da nur schwer die passende Stelle finde.

Selbst wenn ich die Property-Sache erstmal ignoriere und weiter zu MemWrite gehe: Ohne sauberen connect komme ich auch da nicht weiter...


Any ideas?

[tuxedo]

JuMi hat das Repo übertragen und ich bastel schon wieder an der MemWrite Implementierung. Hab mal angefangen meine bisherigen Ergebniss und Erkenntnisse im Wiki aufzuzeichnen:

https://github.com/KNX-on-Arduino/Kn...o-Erkenntnisse

Den Code hierfür muss ich noch einchecken. Aber wenn jemand was dazu weiß: Nur her mit den Infos.

[tuxedo]

Bin gerade wieder ein bisschen an der Implementierung dran.
Hab da gesehen dass ich wohl etwas an der Struktur (Stichwort KNX_COMMAND_ESCAPE und KnxExtendedCommandType) umstellen müsste. Würde das gerne "diskutieren".
Wenn die Github-Organisation schon eine Code-Repo hätte, dann würde ich es da tun.

JuMi2006
Ich will dich ja nicht drängen, aber wie sieht's aus mit der zusammenlegung des Repos? Magst du das in die Wege leiten?

---
Das eigentliche Problem ist, dass es laut Doku wohl keinen wirklichen "KNX_COMMAND_ESCAPE" gibt. Ich hatte den glaub ich so zwischendrin mal eingebaut, aber das passt nicht richtig wenn man das weiter ausbauen will....

[update]
Wenn man wirklich _alles_ unterstützen wollte, müsste man wohl tatsächlich die Struktur ändern. Aber die MemRead/MemWrite Kommandos scheinen wohl doch die zu sein, die nicht im "extended" drin sind. Passt also.... noch!

[tuxedo]

Hab mal ein wenig gebastelt was die abstraktion vom ganzen programmiermodell anbelangt:

Sample-Projekt
https://github.com/tuxedo0801/KnxTpU...4b4b065d6f4ff2
Neue KnxDevice Files:
https://github.com/tuxedo0801/KnxTpU...d725b8992fee46


ist noch lange nicht fertig, aber es kompiliert schon mal und beinhaltet ca. 80% dessen was ich schon anderweitig gebastelt hatte.

[tuxedo]

Ich bestehe nicht auf den Sensoreinsatz. Kann auch was anderes sein. Hauptsache es passt. Da ich bei mir Holzständerwände habe, habe ich sowieso ausreichend Platz in der Wand ;-)

Bzgl. Repo:

Ich kann in der Github KNX-on-Arduino Organisation ein Repo anlegen und mit dem befüllen was bei dir aktuell drin liegt.

Oder du transferierst dein Repo zur Organisation:
https://help.github.com/articles/tra...-a-repository/

... und forkst es für dich wieder.

Das mit dem Transfer wäre wohl die sauberste Sache.

Vorteil der Organisation: Mehr als nur einer kann die Sache (Pull-Requests z.B.) verwalten. So bleibt's nicht am einzelnen hängen.

[Ing-Dom]

das bekommst Du aber nicht auf eine so kleine Platine. Ich versuche gerade den Atmega32u4 (Leonardo) mit USB-Port, Programmiertaster, Programmier-LED und KNX-Klemme auf eine Runde Platine zu pressen die in eine UP-Dose passt.
Das sieht sehr erfolgversprechend aus. Mal sehen was das am Ende kostet.

Saucool! Den Berker-Sensoreinsatz halte ich auch für unpassend. Hast du auch ein passendes Gehäuse im Auge? Das darf man nicht vernachlässigen.
Gut in UP-Dosen passt z.B. das hier: http://www.conrad.de/ce/de/product/531270
Platinengröße (~45x30) müsste vom Gefühl her ausreichen.