Das liegt am XML. Kann es sein, dass du in ETS für ein oder mehrere GAs keine Datentyp gewählt hast. Weil der Fehler sollte nur kommen, wenn kein DPT im XML für einen Datensatz vorhanden ist.
Ich habe das gerade mal abgefangen. Einfach mal updaten und nochmal einspielen.
Das hab ich mir schon fast gedacht. 
Werd ich mir morgen in der ETS mal ansehen.
Danke
Gruß Micha
schau trotzdem mal obs jetzt klappt. der fehler sollte ja trotzdem verhindert werden. und auss neugier was für ein xml war das. das projektxml oder normaler gaexport
Beim öffnen des Splitters kommt weiter die Meldung.
War die projektxml.
Konnte Konfigurationsform nicht laden
<br />
<b>Fatal error</b>: Uncaught TypeError: Argument 1 passed to KNXExtendedSplitter::GetDPTData() must be of the type string, null given, called in /var/lib/symcon/modules/SymconKNXExtended/KNXExtendedSplitter/module.php on line 388 and defined in /var/lib/symcon/modules/SymconKNXExtended/KNXExtendedSplitter/module.php:506
Stack trace:
#0 /var/lib/symcon/modules/SymconKNXExtended/KNXExtendedSplitter/module.php(388): KNXExtendedSplitter->GetDPTData(NULL)
#1 /-(3): KNXExtendedSplitter->GetConfigurationForm()
#2 {main}
thrown in <b>/var/lib/symcon/modules/SymconKNXExtended/KNXExtendedSplitter/module.php</b> on line <b>506</b><br /> (Code: -32603)
Die XML neu laden muss ich nachher am Laptop noch mal testen.
Ich glaube da muss ich doch mehr abfangen. Bis jetzt gehe ich davon aus, dass es immer ein DPT gibt. Kannst du dir die Datei mal sichern, falls du den Fehler in der ETS behebst. Ich würde das gerne sauber abfangen. Vielleicht darf ich deine Datei zum testen haben. Sprich wenn ja könntest du mir die Datei zu kommen lassen per PN.
Hab den Fehler auch mal versucht Blind abzufangen. Kannst es also direkt nochmal testen.
Kann ich dir schicken, wird aber bestimmt erst morgen was.
Werd mehrer nicht sauber parametrierte dpt‘s haben. 
So der Importer sollte das nun abfangen. Wichtig einmal ohne Datei speichern und dann neu hochladen. Ich parse die Datei nämlich nur wenn diese sich auch geändert hat oder neugestartet wurde, um die Last zu reduzieren.
Hallo traxanos,
jetzt kann ich die xml ohne Probleme laden.
Danke
Super. Wenn noch was ist melden.
Überflüssig. Ist immer fragwürdig, ein System neben ein System mit (fast) derselben Funktion zu stellen. Stattdessen ist konstruktive Kritik (also Vorschläge) immer erlaubt und (meist) gewünscht. (Ich wünsche mir, dass der Begriff EIB endlich verschwindet.)
P.S es wundert mich, dass du das mit dem Programmieren so gut hinbekommst. Da es dabei doch so sehr auf Grammatik und Syntax (vulgo Rechtschreibung) ankommt. 
Ich habe ja einige Kritikpunkte vorgebracht, aber es passiert ja nichts. Schau mal in Funktionswünschen. Da gibt es überwiegend nichtmal Feedback drauf.
Hier ein Beispiel: Ein DPT-2 wird mit 2 Variablen abgebildet. Das ist falsch, da ein KNX Telegramm immer beide Werte gleichzeitig enthält. Um also einen bestimmten Wert fest zu senden, müssen also 2 Telegramme geschickt werden → da ich zwei Variablen updaten muss. Und genau so wird es auch in der ETS umgesetzt.
0 = Keine Prio, Aus
1 = Keine Pro, An
2 = Prio Aus
3 = Prio An
Ich behaupte ja nicht, dass vieles nicht anders zu lösen ist. Ich habe ja für fast alles eine Lösung. Aber warum muss man Sachen dauernd kompliziert machen, wenn es auch einfacher gehen würde (ohne Funktionseinschränkung).
Oder das saubere Handling von Aktion und Status. Da haben sich die KNX Macher wirklich mal was cleveres ausgedacht, dass fast allen Smarthomeprodukten fehlt, und dann wird das in Symcon wieder zusammen gematscht wie es alle anderen auch machen. Ja kann man so machen, wird sogar vermutlich den meisten nicht stören.
Das ist definitiv ein berechtigter Einwand. Mir wäre es auch lieber, wenn einfach die KNX Basisimplementierung etwas mehr KNX like wäre. Auch wenn ich für diese Aussage von den eingefleischten Symconanhängern gesteinigt werde. Ich persönlich habe nicht das Gefühl, dass man wirklich eine Verbesserungen ähm. Veränderungen haben möchte.
Also passe ich mir das System so an, das es zumindest für mich deutlich Benutzerfreundlicher wird.
Erfahrungsgemäß haben viele gute Programmier eine Schreibschwäche. Computersprachen habe i.d.R. einfach und logische Regeln. Das ist bei Humansprache nicht der Fall. Ab darauf sollte man in der heutigen Zeit niemanden reduzieren. Ansonsten mein Beileid.
Die Implementierung ist zu 100% KNX Like. Ich hatte es ja schon mal erwähnt: Ich kenne keine Visu, die nicht auf das Haupttelegramm reagiert. Es ist einfach das Prinzip von KNX. Wenn ein AN Telegramm kommt, dann kommt das. Und dann wird das auch so visualisiert. Ob der Aktor hintenrum dann wirklich an ist, wird in diesem Moment nicht berücksichtigt. Ich stimme Dir zu, dass es ein absolut schwachsinniger Zustand ist. In dem Punkt sind wir uns einig. Es liegt aber nicht an der Implementierung von KNX in IP-Symcon, sondern an KNX selbst. Und diesen Punkt beleuchtest Du aus meiner Sicht nicht ausreichend genug bzw. unterstelle ich einfach mal, dass Dir einfach vielleicht auch die KNX Erfahrung fehlt? (nicht böse gemeint)
Lass ihn das doch ändern, wenn das wirklich so ist.
Wie du selber schreibst, ist das völliger Schwachsinn.
KNX bietet ja genau diese Möglichkeiten und wer das in der Anzeige noch zuverlässiger braucht geht noch den Schritt weiter und lässt sich den Zustand noch zyklisch senden um beide System abzugleichen.
Ob man jetzt genau dieses Tool dafür braucht oder das selber mit Bordmitteln bastelt kann ja jeder selber entscheiden.
Aus vielen dieser kleinen Änderungen sind in der Vergangenheit oft Verbesserungen einher gegangen, auch in IPSymcon.
Diese Probleme mit KNX habe ich nicht, aber es ist noch kein KNX-Profi vom Baum gefallen …
Einfach mal einen KNX-Kurs von der KNX-Org besuchen. S. z. B. KNX Grundkurs günstiger! | KNX-Blogger
Welche Probleme mit KNX hast du denn, vielleicht kann man dir hier helfen …
Lasse ich ja auch. Darum geht es hier ja auch nicht. Seine Beiträge lesen sich nur - zumindest für mich - so, dass KNX in IP-Symcon völlig fehlerhaft oder falsch implementiert ist. Und das ist es eben nicht. Es wäre für sehr viele auf dem Markt befindliche KNX Anlagen fatal, wenn die Instanzen nicht auf die Hauptadresse reagieren würde. Ich habe im letzten Jahr einige alte Anlagen gehabt, alle so um 2000 - 2005 errichtet. Dort gibt es schlichtweg keine Rückmeldeadresse. Von daher wäre es fatal, wenn der Hersteller hier jetzt entscheiden würde, nur noch auf die Rückmeldeadresse zu reagieren, nur damit die Implementation von KN X nicht mehr „fehlerhaft“ ist, denn sie ist nicht „fehlerhaft“, sondern genau so, wie man es erwartet und von anderen kennt.
Ja, richtig. Dazu müssen sie aber auch sinnvoll sein 
Bei KNX sprechen wir von einem gewissen Standard und nicht von „wünsch Dir was“.
Und warum unterscheidet man dann bitte zwischen Status und Steuerung? Warum machen das die Hersteller nur. Wenn es sowieso keine Rolle spiel.
Dann kennst du halt wenige. Ich hatte dir ja schon einige gennant. Aber gerne hier auch nochmal ein visuelles Beispiel aus HKKNX.
Sei mir nicht böse, ich mache das nicht erst seit gestern. Und ich kenne sogar die KNX Spezifikation bis auf den Bus runter. Ich musste für diese Umsetzung alle Werte selber umwandeln.
Schade das man hier keine sinnvolle Diskussion führen kann. Der Prototyp sollte erstmal nur neue Möglichkeiten aufzeigen. Und dann hätte man mal über den ein oder anderen Punkt reden können ob das ggf. sinnvoll ist sogar ins Coresystem zu übernehmen.
Das ist richtig, aber wie ich ihn verstanden habe möchte er gerne beides umsetzten und nicht nur an dem alten Standard festhalten, was bei den vielen neuen KNX Geräten auch gar nicht mehr nötig ist.
Um dein Beispiel mit den Visualisierungen noch mal aufzugreifen muss man natürlich auch unterscheiden, das IPS ja nicht nur eine Visu ist, sondern hauptsächlich eine Steuerung und da wäre es mir persönlich schon wichtig den realen Zustand des Aktors zu habe und nicht nur ein flüchtiges Schalttelegramm.
Das geht natürlich jetzt mit IPS so auch schon aber ich denke die Instanzenkonfiguration könnte da noch etwas aufgewertet werden und Variablen die den wirklichen IST-Zustand können auch nicht schlecht sein, wenn die HW es ja hergibt.
Ich wollte nur nicht, das eine Idee, die der Verbesserung beitragen könnte, hier direkt wieder abgewürgt wird.
VG,
Doc
Danke @Doctor_Snuggles
Es wird auch wieder nur auf 1-2 Punkt rum gerieten die einem nicht gefallen. Dabei geht es ja auch noch um paar andere Themen. z.B. die Eingabe der GAs per Textfeld. Oder wenn man die Gruppentelegramme gerne alle weiterleiten möchte z.B. in einer Textdatei oder an einen MQTT Broker. Meine KNX Instanz verarbeitet das Telegramm entsprechend des DPT so dass man die Daten nicht jedes mal selber implementieren muss. Ich hatte auch mal gesehen das hier jemand sich sowas auch schon gebaut hatte (wieder doppelte Arbeit die man sich sparen könnte).
Weil der Aktor eben vielleicht auch mal nicht über seine Hauptadresse geschaltet wird, sondern auch mal über eine Zentraladresse.
Ich finde die Diskussion jetzt nicht völlig abwegig und neue Möglichkeiten aufzeigen ist ja auch vollkommen in Ordnung. Der Bedarf scheint ja auch bei Einigen da zu sein. Da sage ich ja auch nix dagegen. Du musst aber leider auch damit leben, dass es die Situation gibt, dass einer daherkommt und sagt „brauche ich n icht“, denn ich möchte nur aufzeigen, dass IP-Symcon hier nichts falsch macht, wie von Dir dargestellt.
Aus meiner Sicht sollte man eher dort ansetzen, dass man gar nicht erst schalten kann, wenn der Aktor tatsächlich gesperrt ist. Ich unterbinde in solchen Fällen die Schalthandlung als solche. Da weiß jeder sofort: aha, Aktor ist gesperrt. Das ist aus meiner Sicht der bessere Ansatz. Aber das schöne ist ja, dass es jeder so machen kann, wie er es möchte.
Die Eingabe der Gruppenadressen unter „Mehr“ finde ich tatsächlich auch ein bißchen krampfhaft.
