ARDUINO am KNX

[tuxedo]

Meinen letzten Stand findet ihr übrigens hier:

https://github.com/tuxedo0801/KnxTpUart

"Feel free to fork/copy"

[Mag Gyver]

Eine Frage nur zur Verständnis für mich. Meint ihr die Library von ThorstenGehrig oder die Library von tuxedo, bevor er Konnekting ins Leben gerufen hat?

ThorstenGehrig Library kompiliert mit 1.6.9 und 1.8.1 der IDE von Arduino.cc. Getestet habe ich aber diese Library mit der Version 1.6.9. Hatte noch keine Zeit für den Test mit der Version 1.8.1.

tuxedo Library kompiliert mit 1.0.5-R2 und ich glaube, bin mir aber nicht ganz sicher auch mit 1.5.0 der IDE von Arduino.cc. Getestet habe ich es mit 1.0.5-R2.
Die restlichen kompilieren zwar, aber keine Funktion der Makros.

Das sind meine bisherigen Erkenntnisse dazu. Vielleicht hilft es dem ein oder anderen.


Mit freundlichen Grüßen

Mag Gyver

[wintermute]

Gibt es denn noch Interesse daran die Lib möglichst funktionsfähig zu machen?

Nach vielen (eigenen und fremden) Aenderungen bin ich momentan auch an dem Punkt, wo meine bisherigen Sketche nicht mehr kompilieren und mir nicht mehr wirklich klar ist, welche Version der Lib ich denn wann und wo genau benutzt hatte.
Also ja: Hier auch!

[tuxedo]

Ja, aber wohl keiner "von hier":

https://www.knixuino.com/tutorial_1_...au_mega_sn.php

[nonamesleft]

Moin,
hat schonmal jemand versucht den Arduino per SIM-KNX an den Bus anzubinden?

[mars]

Gibt es denn noch Interesse daran die Lib möglichst funktionsfähig zu machen?

+1

[Mag Gyver]

Hallo JuMi2006,

hattest du schon die Möglichkeit und/oder die Zeit die von mir im Post #867 gesendete Library und den Sketch bei dir zu prüfen?

Kannst gerne deine verwendete Library und dein Sketch, der dir Probleme macht zuschicken. Dann schaue ich mir das Ding mal an, wenn es dir recht ist.


Mit freundlichen Grüßen

Mag Gyver

[tuxedo]

Das was ich "damals" aus der Lib mitgenommen hab (das war da, als ich die Lib "aufbohren" wollte, so dass man die Geräte - wie jetzt KONNEKTING - über den Bus programmieren kann), war, dass das Timing in der Lib nicht der knüller ist. Mal konnte ich programmieren, dann kamen Telegramme mal wieder nicht alle so an wie sie sollten etc... Ich hab's dann irgendwann aufgegeben.

Und seit ich Franck Marini's Lib aufbohre weiß ich: Ein korrektes Timing ist alles. Wenn das nicht auf <1ms stimmt, klappt auf einmal gar nix mehr.

Alles in allem: Die Franck'sche Lib ist deutlich strukturierter und hat weniger "just make it work, somehow"-Feeling im Code. Wirkt alles zusammen genommen "weniger gebastelt" und mit "etwas mehr Plan".

[JuMi2006]

Ja, hier :-)

Was hast Du denn vor?

Im Prinzip nix Großes. Soweit ich es sehe gibt es momentan zwei Libs.

Die erste ist die von Thorsten gefundene und ein wenig aufgebohrte. Auf dieser beruht die zweite die ich mit tuxedo mal überarbeiten wollte was aber irgendwie nie dazu kam. Da hab ich auch mit persönlichem Zeitmangel Schuld dran.

In der zweiten wurde auf Bytes bei der GA/PA umgestellt und das Verwenden von Strings als Adresse ermöglicht. Es fehlen aber immer noch ein paar wichtige DPTs und was mir noch mehr Sorgen macht ist dass ich Probleme mit den GAs habe.

Hier bin ich nicht sicher ob es sich um Designfehler in der Lib oder in meinem Sketch handelt, wobei ich eher die Lib im Verdacht habe.

Entweder gehen Telegramme gar nicht raus (betrifft 2ByteFloat) oder gehen an falsche GAs (auch nicht optimal). Ein paar Funktionen laufen auch so noch ins Leere so dass man das mal ganz geordnet anpacken muss. Ehrlich gesagt fehlt mir hierzu allein aber die Zeit und Muse. Ein Programmier-Workaholic passt jedenfalls nicht zu mir falls es darum geht etwas zusammen zu machen. Da braucht es eher geduldige Partner die auch mal was ne Woche liegen lassen.

Sinnvoll wäre es das ganze offen in github zu entwickeln und da auch die Bugs zu sammeln. Das wird sicherlich auch lange dauern.

In kurz: Eigentlich kein konkret höheres Ziel, nur die vorhandene Lib auf Fehler kontrollieren und vollständig machen. Ich vermute da noch irgendwo ein Problem mit Speicheradressierung/Pointern. Zum Ende des Frühjahrs hätte ich gern meinen Smoker stabil am Bus .

Der Sketch ist soweit komplett fertig, scheitert aber echt an einer Stelle mit der Lib.

[tuxedo]

Wieso, ist doch schon geklärt. Außer JuMi mag noch mehr Details nennen. Ich habe fertig.

[dreamy1]

Wollt Ihr das nicht besser in einem separaten Thread klären?

[tuxedo]

bitte fasse es nicht als beleidigend auf:

Nö, passt schon. Ich darf's aber kommentieren, oder?

1. Dein "Mehrwert" interessiert mich nicht.

Das ist ne Ansage. Aber auch Ansichtssache.

2. Wer sagt mir dass es in 5 Jahren noch KONNEKTING gibt? (Arduino IDE wird es mit deutlich höherer Sicherheit geben)

Und wenn es KONNEKTING in 5 jahren nicht mehr gibt, so gibt es JETZT die Suite. Die kann man sich runterladen, und die funktioniert auch in 5 Jahren noch. Das istd as tolle an Nicht-Cloud-Software. So richtig Old-School. Anschaffem haben und behalten und nutzen solange die Hardware es noch unterstützt.

3. Ich will keine Suite downloaden, XML erstellen oder mich da einlesen. Ganz ehrlich, wer da neu ist versteht nur Bahnhof (Suite, DeviceLib, etc.)

Das ergibt sich aus Punkt 1. Wer den Mehrwert partout nicht haben will, der will sich damit - vollkommen logisch eigentlich - damit auch nicht beschäftigen.

4. Ich will keine Funktion "von der Stange" ... es geht um absolute Sonderlösungen (ich lese die Funktelegramme meines BBQ-Thermometers aus) - Prototyping

Dann hast du KONNEKTING und oder Eugens UUPS leider nicht verstanden. Es geht ja absolut nicht um Funktionen von der Stange. Eugen's UUPS ist ein 32u4 mit eingebautem KNX Transceiver und alled möglichen IOs herausgeführt. Quasi ein "KNX Arduino". Einziger Unterschied zum "selbstbau Arduino und Siemens BCU": Das Ding ist kleiner, fast fertig aufgebaut, hat ne LED und nen Taster an Board (den man mit KONNEKTING zum programmieren nehmen kann) und kann auch OHNE KONNEKTING genutzt werden.

Also was ist nochmal das Problem dass neben KONNEKTING eine vernünftige Lib für einfachste Ansprüche existiert?

Da gibt's kein Problem.

[dreamy1]

Gibt es denn noch Interesse daran die Lib möglichst funktionsfähig zu machen?

Ja, hier :-)

Was hast Du denn vor?

[JuMi2006]

Ich mache es mal ganz knapp und bitte fasse es nicht als beleidigend auf:

1. Dein "Mehrwert" interessiert mich nicht. (Ich habe weder PA noch GA von meinem Arduino Schlüsselbrett in den letzten 2 Jahren geändert)
2. Wer sagt mir dass es in 5 Jahren noch KONNEKTING gibt? (Arduino IDE wird es mit deutlich höherer Sicherheit geben)
3. Ich will keine Suite downloaden, XML erstellen oder mich da einlesen. Ganz ehrlich, wer da neu ist versteht nur Bahnhof (Suite, DeviceLib, etc.)
4. Ich will keine Funktion "von der Stange" ... es geht um absolute Sonderlösungen (ich lese die Funktelegramme meines BBQ-Thermometers aus) - Prototyping

Also was ist nochmal das Problem dass neben KONNEKTING eine vernünftige Lib für einfachste Ansprüche existiert?

[tuxedo]

Ich bin vielleicht etwas "befangen" in meiner Meinung, aber:

Ich verstehe dass KONNEKTING einen gewissen Mehr-Aufwand mit sich bringt. Aber der Mehr-Aufwand bringt ja auch einen Mehr-Wert mit sich.

Wenn man z.B. Eugen's UUPS oder MI Schnittstelle nimmt, hat man ein 5min einen Temperatursensor aufgebaut und in in weiteren 20min den Sketch und die XML dafür fertiggestellt. Dann ist das ganze ne runde Sache und man muss in 5 Jahren, wenn doch mal ne Änderung der GAs ansteht, versuchen den Source mit der neuen GA zu compilieren und zu flashen. Suite öffnen, GA ändern, ein klick, fertig programmiert.

Der KONNEKTING Sketch ist nicht so viel länger, und die notwendige XML... Bei nur einem Temperatursensor ist die auch super klein.

Vielleicht mag mich ja mal jemand aufklären wo das Problem genau liegt... Liegts an den zusätzlichen Minuten die mal für die XML braucht? Oder ist es einfach nur zu "undurchsichtig"?