"Arduino am KNX" vs. KONNEKTING

[tuxedo]

Um den "Arduino an KNX" Thread nicht zuzuspammen, versuche ich es mal mit einem neuen Thread.

KONNEKTING hat unter den "DKA Lib" Anhängern irgendwie den Ruf furchtbar kompliziert und aufwendig zu sein. Dass dem nicht unbedingt so ist, zeigt @Eugens Beispiel eines einfaches Sketches/Anwendungsfalles, welcher immer mal wieder als Beispiel für die vermeintliche Komplexität von KONNEKTING angeführt wird:

DS18B20 Temperatursensor am Arduino, welcher einfach in Zeitabstand X die Temperatur auf den Bus sendet...

Der Code ist hier zu finden: https://github.com/Adminius/Konnekti...r/SimpleSensor

Ich hab den Code - damit man nicht erst zu Github muss und direkt hier lesen kann - hierher kopiert und mal die vielen ergänzenden Kommentare weggelassen:

#include <KonnektingDevice.h>
#include "kdevice_SimpleSensor.h"

// include OneWire library
#include <OneWire.h> // https://github.com/PaulStoffregen/OneWire
#include <DallasTemperature.h> // https://github.com/milesburton/Arduino-Temperature-Control-Library

#define PROG_LED_PIN 13
#define PROG_BUTTON_PIN 7
#define ONE_WIRE 5
#define KNX_SERIAL Serial1 // Leonardo/Micro etc. use Serial1


OneWire oneWire(ONE_WIRE);
DallasTemperature sensors(&oneWire);/* Dallas Temperature Library */

long waitTime = 0;
long previousTime = 0;
float currentTemperature = 0;

void knxEvents(byte index) {
    // unused in this sketch
};


void setup() {  
    Konnekting.init(KNX_SERIAL, PROG_BUTTON_PIN, PROG_LED_PIN, MANUFACTURER_ID, DEVICE_ID, REVISION);

    sensors.begin();

    waitTime = (long) Konnekting.getUINT32Param(PARAM_tempPollingTime)*1000;    
}

void loop() {
    Knx.task();
    unsigned long currentTime = millis();

    if (Konnekting.isReadyForApplication()) {

        if ((currentTime - previousTime) >= waitTime) {
           sensors.requestTemperatures();
           currentTemperature = sensors.getTempCByIndex(0);
           Knx.write(COMOBJ_tempValue, currentTemperature);
           previousTime = currentTime;
        }
    }
}

"Code-Overhead" durch KONNEKTING ist quasi nicht existent. Aber gehen wir's mal im Detail durch:

* Includen von zwei Header-Files (Die Header-File "kdevice_SimpleSensor.h" muss man nicht selbst basteln, die wird aus der XML heraus generiert.)
* Eine Funktion die eingehende Events verarbeitet (knxEvents), aber in diesem einfachen Beispiel leer bleiben kann
* Eine Zeile zum initialisieren der Lib (Konnekting.init)
* Eine Zeile zum lesen eines Parameters (Sende-Intervall) aus dem EEPROM (Konnekting.getUINT32Param)
* Eine Zeile die KNX Events im Hintergrund bearbeitet (Knx.task()
* Eine Zeile die prüft, ob es gerade passt die Anwendung auszuführen (Konnekting.isReadyForApplication())
* Eine Zeile die die Temperatur auf dem Bus sendet (Knx.write)

So viel weniger hat man mit der DKA Lib dann auch nicht...
Der Rest ist Code betreffend des Sensors.

Die sagenumwobene und als komplex/aufwendig beschriebene XML ist weitgehend übersichtlich (aber für KONNEKTING zwingend notwendig):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<KonnektingDevice xmlns="http://konnekting.de/xml/KonnektingDevice/v0">

    <Device ManufacturerId="57005" DeviceId="3" Revision="0">

        <ManufacturerName>KONNEKTING</ManufacturerName>
        <DeviceName>SimpleSensor</DeviceName>

        <Parameters>
            <ParameterGroup Name="Temperatur" Id="0">
                <Parameter Id="0" IdName="tempPollingTime">
                    <Description>Cycle [s]</Description>
                    <Value Type="uint32" Default="0000001E" Options="" Min="00000000" Max="000FFFFF"/>
                </Parameter>
            </ParameterGroup>
        </Parameters>

        <CommObjects>
            <CommObject Id="0" IdName="tempValue">
                <Name>Temperature</Name>
                <Function>Value</Function>
                <DataPointType>9.001</DataPointType>
                <Flags>52</Flags>
            </CommObject>
        </CommObjects>

    </Device>
</KonnektingDevice>

Ein Abschnitt der die Parameter, bzw. den einen Parameter beschreibt. Man kann auch komplett ohne Parameter arbeiten und sich im Sketch selbst darum kümmern oder den Wert hart codieren. Aber die paar Zeilen XML für diesen Komfort-Gewinn...

Und ein Abschnitt der das eine KO zum senden der Temperatur bereitstellt. Da kommt man nicht drum herum, da KONNEKTING auf KOs basiert. Der Tag "Name" und Funktion" ist quasi beliebig/Freitext. Wichtig ist der Tag DataPointType und Flags. Das eine definiert den DPT, das andere die KO-Flags. "52" sieht als Flag seltsam aus, aber im Grund gibt es hier nur zwei Standardwerte. Beide kann man der XML Doku entnehmen.

Das meiste kann man per Copy&Paste aus Beispielen ziehen. Das XML Format ist denke ich recht gut in der Doku beschrieben.

Fertig. Mehr ist es nicht. Das einzige "Übel" das ich erkennen kann ist die XML. Aber wenn man bedenkt welchen Komfort man durch die Programmierung via Bus erhält, ist das bisschen XML sicherlich kein Hexenwerk.

Würde mich über Kritik und Kommentare freuen ...

Gruß
Alex

[heckmannju]

Hi Alex,
wie würde den der Code aussehen wenn Konnekting nicht benutzt werden würde?
Vg
Jürgen

[Eugenius]

Ich würde sagen, das kann doch jeder selbst machen und anschließend hier posten. Die "NICHT KONNEKTING" lib ist doch soooo viel einfacher

[tuxedo]

Ich habs mal schnell zusammenkopiert. Ist aber ungetestet!

Gegenbeispiel auf Basis von https://bitbucket.org/thorstengehrig...user-forum/src

#include <KnxTpUart.h>

// include OneWire library
#include <OneWire.h> //https://github.com/PaulStoffregen/OneWire
#include <DallasTemperature.h> //https://github.com/milesburton/Arduino-Temperature-Control-Library

#define ONE_WIRE 5 

KnxTpUart knx(&Serial1, PA_INTEGER(15,15,20));

OneWire oneWire(ONE_WIRE); 
DallasTemperature sensors(&oneWire);/* Dallas Temperature Library */

long waitTime = 0;
long previousTime = 0;
float currentTemperature = 0;

void setup() {  
    Serial1.begin(19200);
    UCSR1C = UCSR1C | B00100000; // Even Parity
    sensors.begin();

    waitTime = 30 * 1000;    // alle 30sek

    knx.uartReset();
}

void loop() {

    unsigned long currentTime = millis();


    if ((currentTime - previousTime) >= waitTime) {
        sensors.requestTemperatures();
        currentTemperature = sensors.getTempCByIndex(0);

        knx.groupWrite4ByteFloat("0/0/3", currentTemperature)

        previousTime = currentTime;
    }
}

Ich finde das weder "kürzer" noch "weniger komplex". Einzig die XML ist in diesem Fall unnötig. Dafür muss man aber das Gerät an den Rechner anschließen, die IDE starten, den Code ändern, neu compilieren und auf das Gerät übertragen um PA, GA oder den Parameter zu ändern.

Das Argument, dass man ja die KONNEKTING Suite zum programmieren braucht: Ja, die braucht man. Aber da diese in sich komplett und ohne weitere Abhängigkeiten ist, funktioniert diese auch noch, wenn KONNEKTING vielleicht irgend wann mal in der Versenkung verschwunden ist. Die Suite steht in diesem Fall der ETS in nichts nach. Im Gegensatz zur notwendigen Code-Änderung in vllt. 10 oder 20 Jahren (falls es mal irgendwo eine Umstellung oder dergleichen gibt), ist die Bedienung der Suite einfacher und komfortabler als die Code-Änderung. Anwendung starten, Parameter ändern, programmieren drücken. Fertig.

Ich will die DKA Lib nicht schlecht machen, nein. Ich will nur der Stimmung "KONNEKTING" wäre

* kompliziert
* überfrachtet
* mit einer steilen Lernkurve verbunden
* blöd weil man die Suite braucht

ein wenig entgegen wirken...

[Mag Gyver]

Hallo tuxedo,

das hat dir doch auch Niemand unterstellt!


Beide Wege habe Vor- und Nachteile. Jeder kann doch für sich selbst entscheiden ob er gerne die eine oder lieber doch die andere Library benützen möchte. Ich für meinen Teil benütze beide Librarys, je nach Anwendungsfall.

Du darfst dies nicht falsch verstehen, wenn Einige sagen "Konnekting ist zu kompliziert, überfrachtet oder ich brauch dazu die Suite, puh XML???".

Das ist auch ein bisschen Geschmackssache. Und über Geschmack lässt sich bekanntlich streiten.


Gruß

Mag Gyver

[tuxedo]

Nein, direkt unterstellt hat es KONNEKTING niemand. Aber das ist so die Stimmung die immer wieder an uns herangetragen wird. Darin wird eben in 9 von 10 Fällen "behauptet" dass KONNEKTING kompliziert und überfrachtet ist. Vor allem wenn man sehr kleine, einfache Dinge machen will, wäre KONNEKTING "viel zu aufwendig".
Dieser Thread stellt nun den faktischen Gegenbeweis (mit Ausnahme der XML vielleicht) dar.... In der Hoffnung, dass wir damit Vorurteile ggü. KONNEKTING weiter abbauen können.

Natürlich darf jeder selbst entscheiden was er für seine Lösung nimmt. Aber wenn das Argument kommt "Die Lib würde den Sketch komplex machen", oder "KONNEKTING" wäre viiiiiiiel zu aufwendig für einfache Dinge (okay, ein klein wenig aufwendiger ist es mit der XML schon, aber eben nur ein klein wenig), dann lasse ich das einfach nicht gelten, weil es einfach nicht der Tatsache entspricht.

Wenn einer sagt "mir gefällt KONNEKTING nicht", oder "ich will partout mit XML nix am Hut haben", dann ist das natürlich ne andere Sache. Eben Geschmackssache. Damit kann ich dann gut leben.

[heckmannju]

Hi,
was bei mir ziemlich abschrekend rüberkommt sind die vielen HWVarianten die bestimmt ihre berechtigung haben...aber halt auf mich und auch bestimmt auf viele ander abschrekend wirken. Bei dem einfachen fall nimmt man eine diese Siemens BCU und legt los...

Frage gibt es diese einfach Beispiel mit dem 1 Wire Sensor als Tutorial mit Einfkaufliste ohne viele Variationsmöglichkeiten die ein Beginner durchspielen kann?

Viele Grüsse
Jürgen

[tuxedo]

was bei mir ziemlich abschrekend rüberkommt sind die vielen HWVarianten die bestimmt ihre berechtigung haben..

Vergiss die HW Varianten. Die sind nur Mittel zum Bastel-Zweck. Ich persönlich mag die auch nicht.

Bei dem einfachen fall nimmt man eine diese Siemens BCU und legt los...

So ist es. Der einfachste und schnellste Einstieg ist dieser hier:

http://www.konnekting.de/konnekting-...x-mit-arduino/

Ein fix und fertiges Tutorial mit dem 1-Wire Sensor gibt es noch nicht. Wir haben leider auch nur begrenzt Zeit. Aber wenn sich da jmd. engagieren will: Gerne. Ich brings dann auch entsprechend auf die Webseite.

Aber Lektion1+2 auf unserer Webseite zeigt schon mal den einfachen HW-Einstieg in die Materie mit ein wenig Hintergrundwissen. Lektion 3, die es noch zu schreiben gilt, wird dann die Software mit ins Spiel bringen. Die Idee mit dem 1-Wire Sensor wäre das eine Möglichkeit.

Das Problem ist halt wie immer: Wenn uns keiner Fragen stellt, können wir nur "raten" und hoffen dass wir in die richtige Richtung laufen. Wir selbst stecken schon zu tief in der Materie drin als dass wir direkt wissen was ein Einsteiger noch an Infos braucht und wo er sie am ehesten erwarten würde. Zumindest was die Doku angeht sind wir auf dem Weg alles zentral über die Webseite erreichbar zu machen.

[heckmannju]

So ist es. Der einfachste und schnellste Einstieg ist dieser hier:

http://www.konnekting.de/konnekting-...x-mit-arduino/

Ein fix und fertiges Tutorial mit dem 1-Wire Sensor gibt es noch nicht. Wir haben leider auch nur begrenzt Zeit. Aber wenn sich da jmd. engagieren will: Gerne. Ich brings dann auch entsprechend auf die Webseite.

Aber Lektion1+2 auf unserer Webseite zeigt schon mal den einfachen HW-Einstieg in die Materie mit ein wenig Hintergrundwissen. Lektion 3, die es noch zu schreiben gilt, wird dann die Software mit ins Spiel bringen. Die Idee mit dem 1-Wire Sensor wäre das eine Möglichkeit.
.

Die beiden Lektionen finde ich schon mal super.. bin schon gespannt auf Teil 3 :-)

[dreamy1]

Ganz fair ist der einfache Vergleich von ein paar Zeilen Code jetzt aber ehrlicherweise nicht, auch die XML fällt ja nicht vom Himmel. Wie man dann mit der .kdevice.xml und .kconfig.xml umzugehen hat, da muss man sich eben auch erstmal einlesen und verstehen: http://www.konnekting.de/software-do...s-kconfig-xml/
Was sich hinter der Manufacturer ID, Device ID und dem Revisionsindex auf sich hat und wo welche Dinge wie im Projektordner abgelegt werden, muss man eben auch erstmal rausfinden bzw. sich einlesen und ob man das nach ein paar Jahren bei einer Änderung noch alles weiß, ist eben auch eine Hürde - gerade für Anfänger und nicht-IT'ler, die von einer XML noch nie was gehört haben...

Mit der bitbucket-Lib sind es halt wirklich nur ein paar Zeilen Code im Sketch, den man eh gerade bearbeitet (und meistens auch versteht) und fertig. Auch wenn sich der zusätzliche Einarbeitungsaufwand in Konnekting sicher lohnt, ist es für Anfänger definitiv komplexer.

Meine ganz persönliche Meinung:
Der Durchdringungsgrad von Konnekting wäre ungemein höher, wenn es zusätzlich (!) sowas wie "Konnekting Light" gäbe. Einfach eine Lib wie die von Thorsten, von Profis programmiert und dokumentiert, die sauber funktioniert, aber ohne Suite und ohne XML. Einfach "hardcoded" im Sketch, statt der tpuart.h bindet man z.B. eine konnekting-light.h ein und man kann ähnlich einfach loslegen - Vorteil: es ist trotzdem noch "Konnekting" mit all seiner Professionalität drin. Könnte wunderbar neben der normalen Konnekting-Welt koexistieren, wenn man auf gewisse Funktionen verzichten kann.

[heckmannju]

Könnte man das XML nicht in Dialogen verstecken in der Suite verstecken und generieren?

[tuxedo]

dreamy1

Ganz fair ist der einfache Vergleich von ein paar Zeilen Code jetzt aber ehrlicherweise nicht, auch die XML fällt ja nicht vom Himmel.

Wer lesen kann ist klar im Vorteil:

Mehr ist es nicht. Das einzige "Übel" das ich erkennen kann ist die XML. Aber wenn man bedenkt welchen Komfort man durch die Programmierung via Bus erhält, ist das bisschen XML sicherlich kein Hexenwerk.

Ja, die XML fällt nicht vom Himmel. ABER:
Es wird immer wieder aufgeführt, dass KONNEKTING nicht für "kleine Dinge taugt". Dabei gibt es jetzt schon Beispielsketches die man in Teilen übernehmen kann. So auch die XML. Ja, das ist ein wenig Aufwand. Aber ich bin davon überzeugt, dass es für den absoluten Anfänger keine Stunde dauert (und der etwas fortgeschrittene Bastler wird mit 30min locker auskommen) um obiges XML Beispiel anhand der Doku zu verstehen und auf eigene Bedürfnisse anzupassen. Und sind wir mal ehrlich:

Eine halbe Stunde oder Stunde extra Aufwand... Fällt das bei solchen Basteleien ins Gewicht? Ich behaupte: Eine Stunde fällt nicht ins Gewicht.
Erst recht nicht, wenn man den Mehrwert dann hat.
Aber wer partout nix mit XML am Hut haben will: Kein Problem. Jedem das seine.
Ich erinnere nochmals: Dieser Thread soll zeigen, dass der KONNEKTING Code weder überfrachtet noch komplex ist. On Top kommt dann halt noch die XML, die aber wirklich kein Hexenwerk ist.

Wie man dann mit der .kdevice.xml und .kconfig.xml umzugehen hat, da muss man sich eben auch erstmal einlesen und verstehen:

Nein, das muss man absolut nicht. Es kann einem völlig schnuppe sein was da intern passiert (ich hab das nur dokumentiert, da der eine oder andere das unbedingt wissen wollte). Oder hast du dich auch schlau gemacht wie die ETS intern ihre Daten in der Datenbank hält und wie die DB-Struktur aussieht?

In der Doku ist (mit Beispielen!) klar beschrieben wie eine .kdevice.xml auszusehen hat und wozu sie gut ist (sie ist das KONNEKTING Pendant zur .knxprod-Datei der ETS).

Was sich hinter der Manufacturer ID, Device ID und dem Revisionsindex auf sich hat

Es hat keiner gesagt dass man ohne Doku lesen auskommt. Aber bitte:

https://github.com/KONNEKTING/Konnek...description.md

After writing your arduino KONNEKTING Device sketch, you should have a list of communication objects and parameters your device will use or provide. To be able to program the device via the KNX bus, you have to provide a XML file which describes your device. This XML file can then be used by the KONNEKTING Suite, which provides a comfortable way of device programming.

3 Sätze... Whoohoo... wie kompliziert.

Weiter steht da auch, dass man, bevor man Anfängt, sich eine "Manufacturer ID zulegen sollte". Es folgt dann ein Link auf https://github.com/KONNEKTING/Konnek...nufacturers.md

Dort steht mit einfachen Worten was diese ID ist, wozu man sie braucht, und wie man an sie ran kommt. Ich zitiere die 5 Sätze jetzt nicht nochmal. Das kann jeder innerhalb 1min selbst lesen.
Und oh wunder: Ohne dass es die Webseite gab, hatten es schon 8 Leute geschafft die Doku zu finden, zu lesen und sich eine ID zu registrieren. Jetzt wo es unsere zentrale Webseite gibt, sollte das in Zukunft noch einfacher werden.

und wo welche Dinge wie im Projektordner abgelegt werden

Das ist auch völlig uninteressant und ist kein Wissen das man haben muss damit alles funktioniert. Die Suite frägt beim ersten Start nach einem Projektordner (bis jetzt...).
Aktuell muss man nur wissen, DASS die Suite ihre Daten in einem Projektordner ablegt. WIE sie das macht interessiert nicht (ebensowenig wie bei der ETS die DB...).
Aber da das hier als "Problem" angeführt wird, nehme ich das mal an Anlass für die Beta5 einen Standard-Projektordner einzusetzen und den Benutzer damit nicht weiter zu verwirren. Oder anders gesagt: Der Benutzer der Suite sieht erstmal nichts von einem Projektordner. Das ganze funktioniert einfach out-of-the-box.

und ob man das nach ein paar Jahren bei einer Änderung noch alles weiß, ist eben auch eine Hürde

Alles bisher aufgeführte (bis auf das erstell3en der .kdevice.xml - was aber den "Geräteentwickler" vorbehalten ist) ist nichts was ein KONNEKTING Benutzer wissen muss um damit zu arbeiten. Ergo stellt es auch keine Hürde dar.
Wer mit der ETS umgehen kann, der weiß von der ETS dass ein Gerät eine Produktdatenbank braucht, damit man es in der ETS verwenden kann.
Bei der Suite ist das exakt genau so. Nur heißt die Datei mit der Endung nicht .knxprod sondern .kdevice.xml ... Mehr unterschiede gibt es eigentlich für den Benutzer (der der ein Gerät nutzen will, nicht der, der es entwickelt) nicht.
Der, der Geräte entwickeln will, der muss nur wissen wie er die .kdevice.xml anlegt. Und hier bleibe ich dabei: Das Format ist recht einfach gehalten, setzt aber voraus dass man lesen kann und auch will. Anhand der Beispiele sollte es keine Stunde dauern bis man die erste XML selbst erstellt hat.
Wenn man die Stunde nicht investieren will, dann ist das eben so. Damit kann ich leben.

gerade für Anfänger und nicht-IT'ler, die von einer XML noch nie was gehört haben...

Und du bist dir sicher, dass der Anfänger und Nicht-IT'ler von C++ Programmierung prinzipiell mehr Ahnung hat wie von XML? Ich behaupte, es ist deutlich schwerer einen funktionierenden Sketch zu erstellen wie eine XML zusammen zu kopieren.

Mit der bitbucket-Lib sind es halt wirklich nur ein paar Zeilen Code im Sketch, den man eh gerade bearbeitet (und meistens auch versteht) und fertig. Auch wenn sich der zusätzliche Einarbeitungsaufwand in Konnekting sicher lohnt, ist es für Anfänger definitiv komplexer.

Einarbeitungsaufwand, ja. Komplex?

kom·plẹx
Adjektiv
gehoben

1. kompliziert, vielschichtig, nicht einfach.

....Nein.

Der Durchdringungsgrad von Konnekting wäre ungemein höher, wenn es zusätzlich (!) sowas wie "Konnekting Light" gäbe. Einfach eine Lib wie die von Thorsten, von Profis programmiert und dokumentiert, die sauber funktioniert, aber ohne Suite und ohne XML. Einfach "hardcoded" im Sketch, statt der tpuart.h bindet man z.B. eine konnekting-light.h ein und man kann ähnlich einfach loslegen - Vorteil: es ist trotzdem noch "Konnekting" mit all seiner Professionalität drin. Könnte wunderbar neben der normalen Konnekting-Welt koexistieren, wenn man auf gewisse Funktionen verzichten kann.

Das gibt es schon, nennt sich "KNX Device", entstammt der Feder von Franck Marini und ist die Basis von KONNEKTING:

https://github.com/franckmarini/KnxDevice

Ich dachte du wüsstest wie KONNEKTING enstanden ist?!

Könnte man das XML nicht in Dialogen verstecken in der Suite verstecken und generieren?

Auf meiner ToDo Liste steht noch ein "KONNEKTING Developer Tool". Das ist eine Anwendung, mit der man Menü/Wizard-geführt eine .kdevice.xml erstellen kann, ohne direkt am XML Code herum zu fingern. Man wird sich damit seine Parameter und KOs einfach zusammen klicken können, und aus dem Ergebnis dann auch direkt die passende .kdevice.xml sowie kdevice-xxxxxxxxx.h Header Datei erzeugen lassen.
Aber bevor ich Arbeit in dieses Tool stecke, muss KONNEKTING erstmal beta5 hinter sich haben und das XML-Format "fertig" sein. Denn hier und da ändert sich das Format gelegentlich noch, um weitere Features und Funktionen zu berücksichtigen. Würde ich das Tool jetzt schon schreiben, müsste ich nicht nur die Suite und deren Lib pflegen, sondern auch noch das Tool. Und das würde die Zeit bis zum "stable release" nur unnötig weiter ausbremsen.

Und zum Schluss:

KONNEKTING ist noch nicht fertig und in Stein gemeißelt. Es fehlt noch an vielen Ecken und Enden bis es richtig "rund" ist. Wir würden uns über helfende (und nicht nur meckernde) Hände freuen. Ist ja kein reines 3-Mann-Projekt.
Dass der Code an sich nicht komplexer als andere Libs ist, wurde hier ja schon gezeigt. Dass man dennoch Zeit aufbringen muss um zu verstehen wie das mit der Gerätedefinition .kdevice.xml funktioniert ist quasi selbstverständlich. Jedoch wurde hier auch versucht zu zeigen, dass man dafür keine 2 Wochen braucht, sondern das in kurzer Zeit verstehen und anwenden kann. Dass dem so ist, zeigen Rückmeldungen die ich hier im Forum und teils per Email (von Nicht-IT'lern) bekommen habe.
Und damit das noch besser wird, wird weiter an der Thematik gearbeitet.

[dreamy1]

Du hast es leider wieder nicht verstanden, was ich geschrieben habe. Ich kann als Beispiel eines absoluten PC-Anfängers zum Schreiben eines Satzes ein Textdokument aufmachen (intuitiv) oder ich kann Word verwenden und ein dickes Handbuch dazu daneben legen - und dem Anfänger mitteilen, dass alles doch so einfach ist und er eigentlich nur zu blöd oder faul ist, sich doch da bitte einzuarbeiten. Warum der Anfänger das tun soll, obwohl es auch einfacher geht, erschließt sich ihm einfach nicht.

Jegliche Kritik an Konnekting wird jedoch sofort wieder als "Meckern" aufgefasst. Die Art und Weise und mittlerweile leider auch Überheblichkeit, wie damit umgegangen wird ("sagenumwobene XML"..."3 Sätze... Whoohoo... wie kompliziert"...), lasse ich mal unkommentiert. Ich kriege übrigens ebenso einiges an Rückmeldungen per PN/Email, die genau das bestätigen, was ich schon vor einiger Zeit dazu geschrieben habe, aber bisher immer abgekanzelt wurde. Aber egal - es macht für mich wenig Sinn, darüber weiter zu diskutieren.

[tuxedo]

Ich sags nochmal:

Der Thread soll nicht belegen dass KONNEKTING einfach/einfacher ist, er soll belegen dass der Code nicht komplizierter ist, die XML mal außen vor gelassen.

Ich hab kein Problem damit wenn jemand sagt es ist ihm den Aufwand nicht wert. Aber wenn KONNEKTING als
* kompliziert
* überfrachtet
* nicht für kleine Dinge brauchbar
hingestellt wird, und so getan wird, als ob es ne ganze Woche bräuchte um für ein kleines Projekt, wo man doch nur die Temperatur auf den Bus bringen will, die passende XML anzulegen, dann kann ich nur entgegnen:

Entweder einlesen (und dann in kurzer Zeit eine Lösung haben), oder es sein lassen und was anderes nutzen.
Aber bitte nicht ohne sich mit der Materie beschäftigt zu haben alles als kompliziert/überfrachtet/unbrauchbar hinstellen.

Warum der Anfänger das tun soll, obwohl es auch einfacher geht, erschließt sich ihm einfach nicht.

Ich weiß nicht wie die ganzen Anfänger da draußen so ticken. Aber wenn ich mich mit etwas neuem (ich bin ja jetzt mal Anfänger) beschäftigen will, dann schau ich erstmal "was gibt es denn so". Und da wird der Anfänger ja auf mittlerweile mind. 3 Lösungen stoßen:

* Die DKA basierte Lib. Da wird er schnell feststellen: Alles steht im Code
* Die Franck Marini Lib. Da wird er feststellen: Okay, hier geht's um KOs, steht aber alles im Code
* KONNEKTING.

Gerade bei KONNEKTING wird es wohl zwei Möglichkeiten für ihn geben:

1) Er wird lesen dass man da über den Bus programmieren kann, aber doch alles so kompliziert sei
oder
2) Er lässt sich davon nicht beeindrucken und beschäftigt sich mit der Materie ein wenig.

Und zuguter letzt entscheidet er sich für eine für ihn passende Lösung. Jede hat ihre absolute Daseinsberechtigung.

Was ich nur vermeiden will ist eben genannter Abschnitt 1)..... Der Vermeidung von einem - wie ich finde - Vorurteil.

Jegliche Kritik an Konnekting wird jedoch sofort wieder als "Meckern" aufgefasst.

Das ist schlicht unwahr. Siehe https://knx-user-forum.de/forum/proj...wendigen-infos
Und siehe auch die Diskussion um die Anzahl KOs...
Daneben noch zahlreiche Emails mit noch mehr Fragen und Kritik, welche wir teils auch schon aufgenommen/umgesetzt haben.

Ein Projekt dieser Art lebt vom mitmachen... Es wird viel an uns herangetragen. Und wir können es leider nicht jedem recht machen, weil die Anforderungen teils recht weit auseinander gehen. Wer orschläge hat wie man etwas besser machen kann ist gerne willkommen. Und wer Code dazu beisteuern kann erst recht.

Eine "KONNEKTING Light" Version auflegen macht wenig Sinn, da es das wie gesagt in Form von Franck's KnxDevice schon gibt. Aber das haben sich wohl die wenigsten wirklich angeschaut. KONNEKTING ist nur die Weiterführung einer von Franck für Masifi erstellten "Spezialversion" die die Programmierung über den Bus erlaubt.

[dreamy1]

Die Einschätzung, was ein Anfänger für kompliziert oder überfrachtet hält, sollte auch dem Anfänger vorbehalten sein. Das ist eine Frage des Blickwinkels - siehe mein Beispiel oben.