"Arduino am KNX" vs. KONNEKTING

[tuxedo]

heckmannju
Ich hab mich mal um Lektion 3 bemüht: http://www.konnekting.de/konnekting-...on-konnekting/
Allerdings geht's darin nicht gleich um einen Beispielsketch, sondern und Grundlegende Dinge wie KONNEKTING aufgebaut ist, wo die parallelen zu KNX/ETS sind und was es mit der XML auf sich hat.

Lektion 4 wird dann voraussichtlich ein komplettes Beispiel enthalten.

[JuMi2006]

Darf ich kurz zusammenfassen (wissenschaftlich):

- der Code ohne KONNEKTING ist bereinigt kürzer (wenn auch nur marginal)
- ohne KONNEKTING brauche ich keine XML
- ohne KONNEKTING brauch ich keine Suite

Beide "Beispielcodes" bilden das gleiche Ergebnis auf dem KNX Bus.
Wer diese Diskussion für ebenso hohl hält wie ich der kann den Beitrag ja anonym liken .
Aber selbstverständlich erlaube ich auch gegenteilige Meinung ohne folgendes "ja, aber..." meinerseits.

P.S.: Dies ist mein erster und letzter Beitrag zu diesem Thema.
P.P.S.: Die Hardwareentwicklungen von KONNEKTING gefallen mir sehr gut.

[henfri]

Hallo,

ich habe vor einiger Zeit ein erstes KNX-Gerät mit Konnekting gebaut.
Ich habe mich damals mit dem Code und auch der XML nicht schwer getan. Das beiliegende Beispiel hilft sehr. Damals war noch blöd, dass die Nummerierung in der XML und dem Sketch unterschiedlich war. Das ist m.W. aber nun behoben. Darüber hinaus war damals die Suite noch etwas ungenügsam, was das LAN Interface anging.

Aber in Summe hatte ich keine Probleme mit den hier genannten Punkten, wenn ich mich recht entsinne.
Den Punkt, dass Kritik nicht richtig angenommen wird, kann ich für das Feedback, das ich gegeben habe überhaupt nicht bestätigen. Im Gegenteil: Es wurde vorbildlich damit umgegangen.

Für mich ist es nicht relevant, welcher Code kürzer ist. Aber ich begrüße eine Dokumentation. Noch besser ist natürlich, wenn keine Dokumentation gebraucht wird, sie aber dennoch da ist.

Ob eine Suite nötig ist, oder nicht hängt stark vom Anwendungsfall ab. Für einen Sensor an den ich nicht ohne Weiteres dran komme: Unbedingt. Für ein Gerät, welches jemand entwickelt, welches aber (auch) von anderen eingesetzt wird: Unbedingt. Für jemanden der für sich alleine, oder für sich und andere "Entwickler" entwickelt: vielleicht nicht (auch wenn es auch hier interessant ist, Parameter ohne USB zu ändern)

Gruß,
Hendrik

[emax]

Vielleicht sollte man mal diesen Blickwinkel versuchen:

1. Die Nutzer wollen den KONNETINGs nichts Böses. Davon sollte man ausgehen.
2. Daraus folgt logisch, dass es einen anderen Grund für die kritische Haltung geben muss.
3. Den gilt es zu finden.
4. Sofern möglich, kann ein Workaround, eine Vereinfachung, was auch immer andacht werden, oder aber plausibel gemacht werden, warum die Dinge so sind wie sie sind.

Um mehr gehts nicht.

Ich bin selber C++ Entwickler, beruflich, seit langen Jahren. Trotzdem ich die Notwendigkeit von XML (die allerdings noch zu gewichten wäre) erkenne, verstehe ich die Ablehnung auf der "Nicht-Profi" Seite, ja sogar bei Profis - wie zum Beispiel mir: XML ist mein absolutes Hass-Format.

Nur: Mir fällt auch nichts Besseres ein. JSON eventuell, aber das ist nur die Fortsetzung der Obfuskation mit anderen Mitteln. Deshalb beiße ich - zumindest beruflich - in den sauren XML-Apfel. Das ist einfach unbequem zu lesen, und im Vergleich zum '*.ini' Format der 80er Jahre eben nicht sehr übersichtlich.

Aber man muss Folgendes bedenken: Für einen einfachen Taster ist eine ein-Zeilen Konfiguration vermutlich ausreichend. Aber SGML/XML/DTD bietet Möglichkeiten, auf die man mit proprietärem Format verzichten müsste.

• XML ist standardisiert.
• XML erlaubt die Definition von Grammatiken.
• XML wird von den Bibliotheken aller gängigen Programmiersprachen unterstützt, man muss das Rad nicht neu erfinden.
• XML kann relationale Informationen speichern. D.h., es kann auf einen anderen Referenzwert innerhalb der XML Struktur verweisen und damit sehr flexible Definitionen ermöglichen.

Das sind nur ein paar der wichtigsten Eigenschaften.

Warum ich persönlich es hasse wie die Pest, ist, dass ich nicht drauf 'grep'en kann, es lässt sich nicht sortieren, und nicht so einfach mit awk, sed und anderen Mittel analysieren bzw. manipulieren. Man muss sich eine XML Datei immer im Ganzen ansehen, um sie zu verstehen: Ein grep auf Zeilenebene ist bei XML sinnfrei. Und es gibt eine ganze Reihe anderer Ärgerlichkeiten.

Ich glaube, dass ich damit nicht alleine stehe, und habe deshalb Verständnis für die Kritik. XML ist für jeden, der es nicht täglich verwendet, einfach intransparent. Da muss man den Durchschnittsuser auch als Entwickler einfach mal verstehen.

Es gibt aber dennoch gute Gründe für die Verwendung von XML. Und die sollten hier mal erklärt werden.

Zunächst habe ich eingangs bereits die wichtigsten Attribute aufgezählt. Wenn man nun ein solches Projekt startet, muss man über dessen Skalierbarkeit nachdenken. Wenn es nur um einfachste Konfigurationen und Hobby-Projekte geht, ist das alles kein Problem.

Schaue ich mir aber die Platinen an, und das bisher geschaffene Umfeld, dann ist doch völlig klar, dass das gar nicht der Fokus von KONNEKTING sein kann. Alles, was ich bisher gesehen habe, ist von professioneller Qualität. Und das bedeutet aus meiner Sicht, dass KONNEKTING auf hohe Skalierbarkeit und ganz andere Kaliber als etwa einen An/Aus Aktor ausgelegt ist.

Ich darf mal als Beispiel einen Gira Tastsensor 3+ nehmen (weil ich den eben ganz gut kenne): Wer so eine Konfiguration ohne Grammatik (DTD) generisch abbilden will, hat schon verloren. Zwar kann man so was als Einzelkämpfer durchaus gut hinbekommen. Aber wenn ich eine erweiterte, zudem tw. auch anonyme Nutzergruppe im Auge habe, kann man Textdateien, Makros u.ä. Konstrukte schlicht vergessen. XML im Zusammenspiel mit einer DTD bietet genau die Möglichkeiten, die so eine hierarchische(!) Struktur braucht.

Hinzu kommt die Unterstützung in den gängigen Programmiersprachen: C, C++, Java, Perl, PHP, Python, alle können das (mehr oder weniger gut, aber immerhin).

Wenn ich nun eine Community unterstützen will/muss, in der ich vom Genie bis zum hoffnungslosen Fall alles habe, was man sich vorstellen kann, dann MUSS ich etwas Standardisiertes, Debug-fähiges, Grammatik-gestütztes als Grundlage nehmen, weil ich im Problemfall sonst bei Sachen anfangen müsste, mit denen man einfach nichts zu tun haben sollte: Die Konfiguration ist ein derartiges "basic-data" Element, dass es einfach Zeitverschwendung wäre, sich mit fehlerhaften und individuell falschen oder mangelhaften Nutzerkonzepten zur Konfiguration auseinandersetzen zu müssen.

Deshalb beiße ich persönlich auch hier in den sauren XML-Apfel, und sehe das Ganze als meinen Beitrag, meine persönliche Vorarbeit zur Erleichterung des Supports und auch zur Standardisierung für größere Projekte an. Und insbesondere Letzteres wird auf Dauer eine Erleichterung darstellen. Man stelle sich vor, es wäre in irgendwelchen *.INI-Dateien nach fehlenden Kommata, Spaces, Tabs und anderem Teufelswerk zu suchen, weil irgendwo im Sketch ein Konfigurationsparameter nicht verstanden wird ...

Den Entwicklern gebe ich zu guter Letzt mit auf den Weg, dass es vielleicht einmal ein Wort wert wäre, wie KONNEKTING überhaupt positioniert sein soll. Denn für mich ist offenkundig, dass das kein knx-user-forums Ding bleiben soll. Ich vermute, dass es in größerer Skalierung auch einmal Geld verdienen soll (was OK ist), und deshalb dieses Forum hier als Plattform nur einen Teil der finalen Zielgruppe darstellt. Ich unterstütze so einen Ansatz, sofern ich damit nicht falsch liegen sollte. Denn Open HW/SW heißt ja nicht, dass man damit kein Geld verdienen darf (siehe Suse, Redhat, Mozilla, Apache, Libreoffice et. al., auch da gibt es reihenweise erfolgreiche Geschäftsmodelle). Absolut OK.

Nur würde ich das dann auch mal kommunizieren, und klar machen, dass XML eben nicht nur für kleine Sachen gedacht ist, sondern für die Zukunft als strategische Lösung ausgewählt wurde. Und davon gibts eben nur eine, Punkt.

So sehe ich das.


PS: Es wäre mal einen Versuch wert, so eine TS3+ Konfiguration in den diversen Projekten darzustellen. Mal sehen, wie weit es mit der Einfachheit dann noch her ist, und welches Kozept bei solchen Anforderungen als erstes aussteigt ...

Das überlasse ich aber gerne anderen, ich habe die XML-Lösung ja akzeptiert. ;-)

[tuxedo]

Danke an emax für die ausführliche Schilderung und auch die Blumen die ich zwischen den Zeilen lesen durfte :-)

XML haben wir gewählt weil (du hast das meiste schon erwähnt):

* man kann es mit vielen Tools bestens parsen und "Fehler" schnell erkennen
* ich kann aus der XML heraus passenden Code generieren um mit den Daten aus dem XML zu arbeiten
* es ist sehr verwandt mit HTML, was doch der eine oder andere bastler schon kennt
* es doch ohne viel Vorahnung mit dem Auge und einem 0815 Editor "lesbar/verstehbar" ist, sofern die XML Struktur "einfach" bleibt.

Gerade der erste und letzte Punkt war mein Hauptargument. Hier ist einiges an Überlegung und Überarbeitung reingeflossen. Vergleicht man unsere XML Struktur mit der eines offiziellen KNX Gerätes (versteckt in der "zip" mit Endung ".knxprod"), so sieht man durchaus, was ich mit "einfacher Struktur" meine.

Sobald ich eben über den Bus ein Gerät einstellen können will, muss ich eine Art "Gerätebeschreibung" haben. Und je nach Gerät ist die eben umfangreich oder weniger umfangreich. Und ein besseres Format als XML ist mir hier auch noch nicht unter gekommen.

Zur Definition wohin KONNEKTING abzielt:

Nach wie vor: DIY KNX Geräte die sich über den Bus parametrisieren lassen. Nicht mehr und nicht weniger.

Und da ich als Hauptberulicher Software Engineer und Consultant den meisten Teil der Softwae schreibe, versuche ich das ganze eben auf eine "möglichst professionelle Ebene" zu ziehen. Hier und da könnte es noch besser sein, aber man nun ja, man tut sein bestes.
Mein persönlicher Wunsch/Traum/<wie auch immer> ist es, dass sich um KONNEKTING ein kleines Ökosystem entwickelt. Und für mich primär um eben Nieschen-Probleme damit zu lösen die die großen Hersteller nicht lösen wollen oder können.

Wenn ich nun ausschließlich meine Probleme für mich löse, hab nur ich etwas davon. Würde mir Arbeit und Mühe ersparen. Aber der Traum vom KONNEKTING Ökosystem würde dann schnell zuende geträumt sein. Und deshalb, und weil es auch ein tolles Hobby ist, forcieren wir auch mit eigenen HW Entwicklungen die wir anderen anbieten diesen kleinen Traum.

Es wäre mal einen Versuch wert, so eine TS3+ Konfiguration in den diversen Projekten darzustellen. Mal sehen, wie weit es mit der Einfachheit dann noch her ist, und welches Kozept bei solchen Anforderungen als erstes aussteigt ...

Ich glaube das wäre wenig zielführend. Dafür sind die Zielgruppen einfach zu unterschiedlich. Die einen Lösen ihr Problem recht schnell und einfach, aber sehr individuell. Dabei spiel die programmierfähigkeit über den Bus eine untergeordnete Rolle.
Und die anderen wollen ggf. sicherstellen, dass man auch in 5-10 Jahren noch bequem vom Rechner aus, ohne extra USB Kabel die Geräteeinstellung aktualisieren kann, oder (wenn beta5 endlich durch ist), mal ein Firmware-Update über den Bus einspielen kann. Das ist dann eine Sache von wenigen klicks, während in der ersten Variante man den Code ggf. neu übersetzten, das Gerät per USB Verbinden und quasi komplett neu programmieren muss. Geht auch, dauert halt ggf. ei wenig länger. Ist halt nur ein anderer Ansatz. Jedem das seine.

[emax]

Zitat:
"Es wäre mal einen Versuch wert, so eine TS3+ Konfiguration in den diversen Projekten darzustellen. Mal sehen, wie weit es mit der Einfachheit dann noch her ist, und welches Kozept bei solchen Anforderungen als erstes aussteigt ..."

Ich glaube das wäre wenig zielführend. Dafür sind die Zielgruppen einfach zu unterschiedlich.

Um Missverständnissen vorzubeugen: Meine implizite Prophezeihung des "Aussteigens" gilt nicht KONNEKTING, sondern den anderen Lösungen. Eben weil XML das stemmen kann, "einfache" Lösungen aber nicht (so ohne weiteres).

Die TS3+ Konfiguration war für mich ein proof-of-concept für eigene, "XML-freie" Ideen, einige Zeit zurück. Ich bin mehrfach gescheitert. Am Schluss hab ich es mit perl gemacht, was ganz vortrefflich ging (weil mit perl eben alles geht). Aber das ist für 'da draussen' einfach keine Option.

Ich finde, Ihr habt soweit die richtigen Ansätze gewählt. Insofern gibts tatsächlich Blumen ;-)

Macht weiter so.

[MaLcoLmX]

Hallo,

wie genau erzeuge ich denn die kdevice_simpleSensor library? Erfolgt dies über die KonnektingSuite? Habe gerade mit Konnekting angefangen und beim ersten Versuchsaufbau soweit eig. alles hinbekommen bis auf das Erzeugen der Library.

[tuxedo]

Melde dich doch am besten im KONNEKTING Board hier im Forum. Da würde das schon mal thematisiert.

Gruß Alex