GA Flags aus der KNXPROJ werden falsch übergeben

[teddysdl]

Wenn ich mein Projekt einlese, dann werden hauptsächlich die flags der dpt1.001,dpt1.011 und dpt5.001 falsch gesetzt, betrifft gefühlt 90% aller GA´s. Kann mir jemand einen Tipp geben was ich besser machen kann? Der Server wurde vor 1 Monat frisch aufgesetzt. ETS5 5.7.2 Pro (ETS Projekt erstellt in der ETS 5.5) KNX Adapter in ioBroker 1.0.42 und 1.0.39 bei beiden das gleiche Problem. Node.js v12.20.1 NPM 6.14.10

[chefkoch009]

Mach mal ein Update des Adapters auf 1.0.44.

[teddysdl]

musste wieder auf 1.0.42 downgraden.

[chefkoch009]

Naja, bei soetwas empfehle ich vorher einen JSON Export vom knx.0 Objekt Baum. Diesen Baum im Admin anschließend löschen, den Adapter upgraden und das ETS Projekt neu importieren. Sollte dies schief schlagen, den eben erzeugten knx Baum wieder löschen, das downgrade durchführen und anschließend die zu Beginn erzeugte JSON wieder einspielen.

[teddysdl]

Das Fehlerbild bleibt unverändert, der Adapter bleibt rot. Deine Empfehlung bin ich nachgekommen, mit einer kleinen Abweichung und zwar habe ich den KNX Adapter komplett gelöscht , neu installiert und eingerichtet. Aber ohne Erfolg.

[RESDE]

@teddysdl Was heist vor 1 Monat wurde der Server neu aufgesetzt? Hast Du einen Server als KNX/IP Schnittstelle oder aber ein neuen Server auf dem IOBroker läuft?

Dann zur Sicherheit im Objektbaum den Knoten KNX.x und alle Unter-Elemente löschen (rechter Hand auf den Mülleimer) Am besten die aktuellste Version des KNX Adapters verwenden/Installieren. Dann nochmals die ETS Projektdatei importieren via Adapter Options.

Dann in die Struktur Deiner ETS Datei einsteigen (Siehe Anleitung, das Problem beginnt schon in der ETS nicht erst im KNX Adapter... ;-) Stell mal Deine GA 8/4/20 (die linke in Deinem Post oben) im ETS Device auf das Flag Ü, das ist nicht aktiviert. Da Du keine Angaben über Dein ETS Device machst, ist das schwierig zu erraten. Schau mal im ETS Handbuch für dieses Device nach, wie die richtige Flags gesetzt werden sollen. Im bereich Issues in diesem Github kannst Du ähnliche Probleme und Lösungen Dir durchlesen. Hoffe Du kommst weiter..

[AlexW85]

Habe das selbe Problem...

@RESDE Die Flags sind genau richtig und zumindest bei größeren Objekten sollte man unbedingt vermeiden hier mehr anzuklicken!

Der Wrapper der die knxproj File einliest sieht das aber wohl anders und kann nur mit falsch konfigurierten Flags umgehen?! Bei mir gibts auch keine Referenz zum Status Objekt. Ich bin schon wieder kurz davor mir die Arbeit über XML Export, Excel Makros und in FHEM einfügen zu machen, weil alleine dieses Verhalten "Ich rufe jetzt mal alle States beim Neustart ab, kannste machen was du willst" ist höchst unprofessionell bei mehr wie EFH mit einer Linie.

Dann kann man ja in ioBroker auch nicht einfach alle Objekte gleichzeitig markieren und berichtigen, sondern höchst umständlich alle einzeln.

Was geht ist die Flags falsch setzten, alle Koppler auf Durchzug schalten, die Konfig einlesen und am Schalter das Licht einmal schalten, in dem Moment wird dann in ioBroker der Datensatz korrigiert und ab dann geht es auch mit filtern und richtigen Flags...

Hier die Definition der KNX Flags:

L-Flag (Lesen): Das Kommunikationsobjekt ist vom Bus aus lesbar (für z.B. Statusabfragen, es sollte pro GA nur ein Gerät dieses Flag aktiviert haben)!

S-Flag (Schreiben): Das Kommunikationsobjekt ist vom Bus aus beschreibbar.

Beispiel: Aktorkanal (K,S) reagiert auf den Schreibbefehl vom Bus, den ein Taster (K,Ü,A) an den Bus gesendet hat

Ü-Flag (Übertragen): Das Kommunikationsobjekt sendet ein Telegramm mit dem neuen Inhalt, wenn dieser geändert wird.

Beispiel: Taster sendet EIN (K,Ü,A) an den Bus und Aktorkanal reagiert auf den Schreibbefehl vom Bus (K,S)

A-Flag (Aktualisieren): Wertantwort-Telegramme von anderen Busteilnehmern werden als Schreibbefehl erkannt. Der Wert des Kommunikationsobjektes wird also den Antwort-Telegrammen entsprechend geändert (aktualisiert).

[teddysdl]

@RESDE danke für deinen Vorschlag, aber die Flags werden bei mir automatisch beim Verteilen der GA´s gesetzt. Ich denke das einfach meine GA Namensgebung ungeschickt gewählt ist und der Adapter damit Schwierigkeiten hat, aber darauf wurde in der Adapterbeschreibung hingewiesen, hätte ich die zuerst gelesen, dann hätte ich euch und mir viel Zeit erspart.

@AlexW85 es ist mir noch nicht aufgefallen, dass alle States beim Adapterneustart abgefragt werden. Das erklärt einiges. Die Last steigt gefühlt für 30sec um 60%, dass ist jetzt nicht weiter schlimm. Aber klar bei größeren Umgebungen ist der Bus erstmal dicht. Aber wichtig zu wissen. Komm auch frisch aus der FHEM Ecke, aber für mich gibt es kein zurück.

[AlexW85]

Ich bleibe auch bei ioBroker, ABER nebenher läuft noch FHEM auf der selben Kiste, weil ich noch EnOcean geraffel habe und das läuft 1A in FHEM mit dem Raspberry HAT. Mit dem FHEM Adapter kann man dann von ioBroker auf EnOcean über FHEM zugreifen 🥴

KNX läuft aktuell auch wesentlich flüssiger auf FHEM, daher die Überlegung...

In ioBroker kann man dafür dank javascript ganz andere Dinge realisieren und es gibt viel mehr Möglichkeiten, auch die Visu ist wesentlich besser!

---

---- Dieser Abschnitt bringt leider auch nix, also wieder richtig flaggen und mit FHEM und FHEM Adpater arbeiten... ----

Ich gebe jetzt als letzten Versuch jedem Schalt-/Dimmaktor auf dem Schalten Kanal jetzt noch das L-Flag (wichtig ist das pro GA nur einer das L-Flag hat und das sollte der sein der den Strom schaltet, also kein Taster, Präsenzmelder etc) und hoffe das es dann nach neuem knxproj Import tut. Richtig ist es zwar nicht, da dies ja eigentlich über den Status/Rückmeldewert erfolgt, aber es sollte keine großen Auswirkungen auf den Traffic haben...

---

Das mit dem Lesen der States beim Start ist natürlich praktisch um diese konsistent zu haben, aber wenn der Server online ist und alles mal durchgeschaltet wurde Ist es das mit der Zeit dann auch!

[teddysdl]

Wer weiß was für Seiteneffekte endstehen, wenn man die States nicht prüft. Vielleicht kann man die Prüfung auf x Anfragen pro Sekunde beschränken, vielleicht greift ja die Einstellung "Pakete pro Sekunde" unter "KNX Gateway IP" auch für die Überprüfung. Ich gib dir recht, im FHEM läuft KNX etwas flinker, aber der KNX Adapter hier macht es schon echt sehr gut. Es sind nur Kleinigkeiten, die einen Anfangs etwas straucheln lassen, aber einen nicht aufhalten (wenn man nicht alles in der Adapterbeschreibung liest^^). Was ich mir noch wünsche ist, wenn das Häkchen bei "Füge nur neue Objekte hinzu" beim Speichern bestehen bleibt.

[RESDE]

@AlexW85 ich kann aus Deinen vielen Details zur Logik des ETS Bus annehmen, dass Du ein ETS Profi bist. Sehr schön dass Du diesen Adapter benutzt und ihn in den direkten Vergleich zu FHEM stellst. Wir haben dennoch Glück dass user teddysdl dennoch sich weiter in den KNX Adapter des IOBroker weiter einarbeiten will. Meine Empfehlung an teddyDSL war, das Ü Flag zu setzen, damit Änderungen in den BUS gesendet werden. Du schreibst ebenfalls in Deiner sehr guten Erläuterung der Flag Funktion in der ETS, dass eine Übertragung an den Bus gesund ist. Wieso stoppst Du dann quasi verbal meine Empfehlung? Hat teddydsl nicht das Recht auszuprobieren, was für Einstellungen "gesund" sind dass der KNX Adapter funktioniert? Und wenn Du schreibst, dass Du das L Flag auf den Schaltaktor zum Ausprobieren verändern willst, naja dann meine ich, dass Du die ETS Flags mit Füßen trittst. Ich kennen zwar nur 4-5 Hersteller von Schaltaktoren, aber die werden immer mit S-Flags geschaltet, niemals mit L-Flags. Status-KOB der ETS jedoch werden wiederum mehrheitlich mit L Flags versehen. Aber schön dass wir hier über das Flagging uns austauschen... . Das schreibst von einem gleichen Problem wie TeddyDSL: zeigt Dein log die gleichen Fehlermeldungen wie Teddy? Dann bitte auch nochmals die Installation überprüfen zumal ihr parallel noch andere Plattformen etc auf eurem Host installiert habt, ich vermute dass daher auch die Fehler resultieren könnten...

@teddysdl: hast Du die aktuelle Version installiert wie von Chefkoch empfohlen? Die Fehlerlog resultiert aus einem nicht möglichen Zugriff auf die Dateien und hat etwas mit der Erstinstallation und nicht dem import der KNX Datei zu tun... am besten dann nochmals auch die Adapterinstanz löschen und bei IOBroker host die richtige Schreib-Leserechte benutzen (Siehe Stichworte im IOForum zum Thema Installation in Root etc) Wenn Du magst kannst Du mich im IOBroker Forum als RES_DE user antiggern und schickst mir Deine ETS Projektdatei, dann schaue ich gerne die GA Struktur mir an... oder Du schickst nur den GA Report der ETS, dann mach ich zwei drei Plausichecks. Die Hinweise von @AlexW85 an Dich bzgl. der Funktiionsweise ist schön zu lesen, er hat die Anleitung gelesen.... Nicht falsch verstehen, wir helfen gerne bei Newies des KNX Adapter, jedoch starten manche User dann direkt mit dem Vorwurf, dass der Adapter nicht funktioniere. Solchen support macht dann nicht wirklich Spass... ;.-)

[chefkoch009]

Moin.... mir klimpern vor lauter Text schon die Augenlider. ;-) Was war eigentlich nochmal das Problem? Es wäre schöner, wenn man sich dem eigentlichen Problem kurz und prägnant widmen würde. Über die anderen philosophischen Themen kann man ja auch gern plaudern, aber bitte wo anders.

...wollte auch mal was sagen.

Nachtrag: persönliche Animositäten und irgendwelche Meinungen haben nichts in einem "issue" zu suchen.

[AlexW85]

@AlexW85 ich kann aus Deinen vielen Details zur Logik des ETS Bus annehmen, dass Du ein ETS Profi bist. Sehr schön dass Du diesen Adapter benutzt und ihn in den direkten Vergleich zu FHEM stellst. Wir haben dennoch Glück dass user teddysdl dennoch sich weiter in den KNX Adapter des IOBroker weiter einarbeiten will. Meine Empfehlung an teddyDSL war, das Ü Flag zu setzen, damit Änderungen in den BUS gesendet werden. Du schreibst ebenfalls in Deiner sehr guten Erläuterung der Flag Funktion in der ETS, dass eine Übertragung an den Bus gesund ist. Wieso stoppst Du dann quasi verbal meine Empfehlung? Hat teddydsl nicht das Recht auszuprobieren, was für Einstellungen "gesund" sind dass der KNX Adapter funktioniert? Und wenn Du schreibst, dass Du das L Flag auf den Schaltaktor zum Ausprobieren verändern willst, naja dann meine ich, dass Du die ETS Flags mit Füßen trittst. Ich kennen zwar nur 4-5 Hersteller von Schaltaktoren, aber die werden immer mit S-Flags geschaltet, niemals mit L-Flags. Status-KOB der ETS jedoch werden wiederum mehrheitlich mit L Flags versehen. Aber schön dass wir hier über das Flagging uns austauschen... . Das schreibst von einem gleichen Problem wie TeddyDSL: zeigt Dein log die gleichen Fehlermeldungen wie Teddy? Dann bitte auch nochmals die Installation überprüfen zumal ihr parallel noch andere Plattformen etc auf eurem Host installiert habt, ich vermute dass daher auch die Fehler resultieren könnten...

@teddysdl: hast Du die aktuelle Version installiert wie von Chefkoch empfohlen? Die Fehlerlog resultiert aus einem nicht möglichen Zugriff auf die Dateien und hat etwas mit der Erstinstallation und nicht dem import der KNX Datei zu tun... am besten dann nochmals auch die Adapterinstanz löschen und bei IOBroker host die richtige Schreib-Leserechte benutzen (Siehe Stichworte im IOForum zum Thema Installation in Root etc) Wenn Du magst kannst Du mich im IOBroker Forum als RES_DE user antiggern und schickst mir Deine ETS Projektdatei, dann schaue ich gerne die GA Struktur mir an... oder Du schickst nur den GA Report der ETS, dann mach ich zwei drei Plausichecks. Die Hinweise von @AlexW85 an Dich bzgl. der Funktiionsweise ist schön zu lesen, er hat die Anleitung gelesen.... Nicht falsch verstehen, wir helfen gerne bei Newies des KNX Adapter, jedoch starten manche User dann direkt mit dem Vorwurf, dass der Adapter nicht funktioniere. Solchen support macht dann nicht wirklich Spass... ;.-)

Bist du der Programmierer weil du dich so persönlich angegriffen fühlst? :) Dann bin ich ab sofort still, denn darauf hab ich keine Lust und bau mir in meinem Keller dann was eigenes wie mit VBus und Artnet hier auch. Wenn du verstehst das es nicht richtig funktioniert und Flags setzen die da nicht hingehören keine Lösung ist, dann können wir gerne weiter kommunizieren.

Wie ich KNX Profi wurde: Ich musste mir KNX notgedrungen beibringen, da der Elektriker, bzw. das mittlerweile insolvente sehr große Elektrounternehmen (Imtech) im Unternehmen leider kein Profi war. Ich habe dort die komplette Gruppenadressierung neu aufgebaut (Gab keine Struktur) mit 29 Linien, 700 Geräten und 2 Hauptlinien. Aktuell gibt es rund 2000 Gruppenadressen, wird aber noch mehr, da vieles fehlt. Der Elektriker hatte z.B. aus Verzweiflung jedem Taster alle Flags gegeben und die Aktoren hatten teilweise auch alle und waren dann noch teilweise auf Weiterleiten etc. gestellt. Das das alles nicht wirklich funktioniert hat (Das Licht ging zwar irgendwie an, aber nur widerwillig und mit maximaler Busauslastung und oftmals auch Störungen, da Dimmer durch dieses resultierende Aufschaukeln des Dimmwerts ausgestiegen sind)

Was mein Problem mit dem Adapter ist: Stell dir einfach vor du hast irgendwo in einem der 29 Linien ein Gateway sitzen, wegen der Visu muss sowieso vieles über die Hauptlinie in die Linie mit dem Gateway gesendet werden. Das kann bei der Größe schon eine riesen Buslast werden, KNX ist mit seinen 9600Baud da sehr schnell an der Grenze. Setzt du da jetzt noch ein Ü-Flag, verdoppelt sich die Last auf der Hauptlinie, weil der Aktor allen mitteilt das er jetzt schaltet und dann nochmal (über die Rückmeldung) das er geschaltet hat. Das vernichtet schon fast den Sinn eines Kopplers! Die Flags müssen so sein wie beschrieben, da hat kein ioBroker Adapter etwas anderes zu erwarten, sondern muss sich danach richten. Meine GA Struktur für Beleuchtung ist folgende (Mittelgruppen sind für Etagen, 0 ist also UG):

1/0/0 Lampe x Ein/Aus 2/0/0 Lampe x Rückmeldung 3/0/0 Lampe x Dimmwert relativ 4/0/0 Lampe x Dimmwert absolut 5/0/0 Lampe x Rückmeldung Wert

1/0/0, 3/0/0 und 4/0/0 ist nur der Schaltbefehl, der muss unidirektional vom Gateway/ioBroker über die Koppler zum Aktor gelangen, was lokale Taster oder Touchpanels da rumsenden interessiert niemanden außerhalb der Linie, außer sein Partner befindet sich in einer anderen! :)

2/0/0 und 5/0/0 ist die Rückmeldung vom Aktor die unidirektional in die andere Richtung zum Gateway/ioBroker fließt.

Der KNX Adapter muss den State des Schaltbefehls mit der zugehörigen Rückmeldung verknüpfen und aktualisieren. Es gibt da die Grundlage, allerdings klappts nicht beim Import. Das mit dem Import wäre generell das Knallerfeature überhaupt bei der Dimension, aber ich würde es ja auch selbst anlegen (muss ich bei FHEM oder diesem merkwürdigem OpenHAB ja auch), nur weiß ich nicht was das hier zu bedeuten hat:

"addressRefId": "P-0CD1-0_GA-1254",
"objRef": "O-150_R-6698",
"devName": "M-0002_A-A03B-20-D31A",
"devInst": "P-0CD1-0_DI-2324",

Hier mal ein Beispiel eines Lichts mit der Rückmeldung dazu. Die Bezeichnung sollte nicht das Problem sein { "_id": "knx.0.Beleuchtung_E_A.2OG.2_0_73_Flur_Beleuchtung_E_A", "type": "state", "common": { "name": "2.0.73 Flur Beleuchtung E/A", "type": "boolean", "role": "indicator", "read": true, "write": false, "update": true, "unit": "", "max": true, "min": false }, "native": { "dpt": "DPT1.000", "address": "1/3/18", "addressRefId": "P-0CD1-0_GA-1254", "statusGARefId": "", "actGARefId": "", "objRef": "O-150_R-6698", "devName": "M-0002_A-A03B-20-D31A", "devInst": "P-0CD1-0_DI-2324", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1612450806589, "acl": { "object": 1638, "state": 1638 } }

Hier ist die Rückmeldungs GA dazu:

{ "_id": "knx.0.Beleuchtung_Status_E_A.2OG.2_0_73_Flur_Beleuchtung_Rück", "type": "state", "common": { "name": "2.0.73 Flur Beleuchtung Rück", "type": "boolean", "role": "value", "read": true, "write": true, "update": true, "unit": "", "max": true, "min": false }, "native": { "dpt": "DPT1.000", "address": "2/3/18", "addressRefId": "P-0CD1-0_GA-1255", "statusGARefId": "", "actGARefId": "", "objRef": "O-169_R-6703", "devName": "M-0002_A-A03B-20-D31A", "devInst": "P-0CD1-0_DI-2324", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1612450806591, "acl": { "object": 1638, "state": 1638 } }

Das Problem ist einfach das zwei States angelegt werden, die nicht in Verbindung stehen und read, write, role und update (eigentlich alles) auch völligst falsch gesetzt werden.

Ist ja auch nicht schlimm, vlt. hat die ETS wieder was geändert was dazu führt das die knxproj Datei anders aussieht. Wobei eigentlich ist es doch schlimm wenn der Adapter 100€ kostet. Das ist er zwar auf alle Fälle wert, aber dann muss er auch gescheit funktionieren. Es wäre schön wenn es funktioniert, denn ich will ioBroker auch gerne als Gebäudevisu im Unternehmen einsetzen! Mit eingeschnappte Leberwurst, Schuldzuweisungen und anderen ihren KNX Bus zu verhuntzen kommen wir aber nicht ans Ziel!

[chefkoch009]

Ich glaube, mein letzter Eintrag war zu kurz gehalten und wurde deshalb überlesen.

Eine Frage drängt sich mir bei der GA Struktur allerdings auf: Wie würde das ganze denn aussehen, wenn Jalousien und Heizung dazukommen?

Ich habe festgestellt, das auch namhafte Hersteller ebenfalls beim Start die States abfragen, auch in solchen riesigen Mega Strukturen.

Der Versuch mit einem Schraubendreher einen Nagel in die Wand zu bekommen wird vermutlich scheitern. Ich persönlich würde mich an dieser Stelle über den Nagel aufregen.

Zum Preis: 100€ sind netto. Mit MwSt sind es 119,00€.

Aber gut, ich mit meiner bescheidenen Erfahrung bin ja auch kein KNX Profi und wie man vllt sieht hat es auch niemanden voran gebracht. Aber es liest sich nett...finde ich.

[AlexW85]

Ich glaube, mein letzter Eintrag war zu kurz gehalten und wurde deshalb überlesen.

Eine Frage drängt sich mir bei der GA Struktur allerdings auf: Wie würde das ganze denn aussehen, wenn Jalousien und Heizung dazukommen?

Ich habe festgestellt, das auch namhafte Hersteller ebenfalls beim Start die States abfragen, auch in solchen riesigen Mega Strukturen.

Der Versuch mit einem Schraubendreher einen Nagel in die Wand zu bekommen wird vermutlich scheitern. Ich persönlich würde mich an dieser Stelle über den Nagel aufregen.

Zum Preis: 100€ sind netto. Mit MwSt sind es 119,00€.

Aber gut, ich mit meiner bescheidenen Erfahrung bin ja auch kein KNX Profi und wie man vllt sieht hat es auch niemanden voran gebracht. Aber es liest sich nett...finde ich.

Habs schon gelesen, war aber zu nett geschrieben, :) Jalousien usw. haben dann höhere Hauptgruppen... ;)

Hab jetzt übrigens alle Geräte und alle GAs in einem Testprojekt rausgelöscht, bis auf die GAs für Licht und die Aktoren die es schalten. Die knxproj ist jetzt 3MB groß. Beim import kommen jetzt andere Ergebnisse heraus, aber stimmt leider immer noch nicht?! ETS ist übrigens 5.7.4.

Wenn dann werden Rückmeldungen abgefragt... Ein initiales einmaliges lesen ist auch was anderes wie nach jedem Start des Adapters.

Werde jetzt nochmal die Sonderzeichen (.,-_/) aus der Bezeichnung löschen

[chefkoch009]

Bei höheren Hauptgruppen kann es bei Kopplern zu Routingproblemen kommen. Bei den Beschriftungen wird simelarity von 96% nicht erreicht. Deshalb findet auch keine Zuordnung statt. Der Wert könnte erhöht werden, wenn die GA's ungefähr so heißen würden: Beleuchtung_E_A.2OG.2_0_73_Flur_Beleuchtung_E_A Beleuchtung_Status_E_A.2OG.2_0_73_Flur_Beleuchtung_E_A. Für den Fall das per ETS kein DPT angegeben ist, geht der Adapter von der absoluten Basic Konfiguration aus also DPT1. Infolge dessen setzt der Adapter weiterhin read=true UND write=false. Das entspricht dem Ü-Flag. Dies ist eine reine Vorsichtsmaßnahme, um nicht eventuell Sachen auf dem Bus zu tun, welche fatale Auswirkungen haben könnten. Besser wäre es den DPT1.001 für Schalten zu setzen und für E/A das Wort Schalten zu verwenden. E/A ist für den Parametrisierer klar, aber der Adapter weiß nicht ob es eventuell so etwas wie GaragE/Aussen ist.

Leider ist es seit ETS5 nicht mehr möglich das Schreibende Objekt einer GA so einfach herauszufinden, deshalb hat sich der Entwickler wohl dazu hinreißen lassen, diesen Weg zu gehen. Dies ist gut vor allem für diejenigen, welche gerade erst begonnen haben sich mit dem Thema KNX zu beschäftigen. Dabei wird eine gewisse Disziplin im ETS Projekt verlangt, was im ersten Moment etwas stringent scheint. Es wird aber sehr schnell klar, das sich der Mehraufwand lohnt, denn die Zeit für bei der Fehlersuche im KNX-Projekt verringert sich dadurch rapide.

[AlexW85]

Bei höheren Hauptgruppen kann es bei Kopplern zu Routingproblemen kommen. Bei den Beschriftungen wird simelarity von 96% nicht erreicht. Deshalb findet auch keine Zuordnung statt. Der Wert könnte erhöht werden, wenn die GA's ungefähr so heißen würden: Beleuchtung_E_A.2OG.2_0_73_Flur_Beleuchtung_E_A Beleuchtung_Status_E_A.2OG.2_0_73_Flur_Beleuchtung_E_A. Für den Fall das per ETS kein DPT angegeben ist, geht der Adapter von der absoluten Basic Konfiguration aus also DPT1. Infolge dessen setzt der Adapter weiterhin read=true UND write=false. Das entspricht dem Ü-Flag. Dies ist eine reine Vorsichtsmaßnahme, um nicht eventuell Sachen auf dem Bus zu tun, welche fatale Auswirkungen haben könnten. Besser wäre es den DPT1.001 für Schalten zu setzen und für E/A das Wort Schalten zu verwenden. E/A ist für den Parametrisierer klar, aber der Adapter weiß nicht ob es eventuell so etwas wie GaragE/Aussen ist.

Leider ist es seit ETS5 nicht mehr möglich das Schreibende Objekt einer GA so einfach herauszufinden, deshalb hat sich der Entwickler wohl dazu hinreißen lassen, diesen Weg zu gehen. Dies ist gut vor allem für diejenigen, welche gerade erst begonnen haben sich mit dem Thema KNX zu beschäftigen. Dabei wird eine gewisse Disziplin im ETS Projekt verlangt, was im ersten Moment etwas stringent scheint. Es wird aber sehr schnell klar, das sich der Mehraufwand lohnt, denn die Zeit für bei der Fehlersuche im KNX-Projekt verringert sich dadurch rapide.

Ok danke, da ich am WE ja nix besseres zu tun habe als für die Arbeit was auszutesten, hab ich die "Suchen und Ersetzen" Funktion der ETS mal ans Limit getrieben! :)

Ich habe jetzt tatsächlich Erfolge damit:

Zwischendurch hatte ich beim Schaltobjekt "2O63 Flur Beleuchtung schalten" und beim Status "2O63 Flur Beleuchtung Rück" aber das war schon zu unterschiedlich! Hiermit wird alles korrekt angelegt!

Jetzt sieht es (zumindest bei normalem Ein/Aus und Rückmeldung) schonmal besser aus, wenn sich das als nutzbar herausstellt hat der Entwickler dieses Adapters einen neuen Unterstützer! :) Ein Javascript für Artnet was ich vor langer Zeit für zuhause geschrieben habe und schon seit Jahren einwandfrei mit einem einfachen Raspberry mit RS485 HAT und OLA der auf DMX umsetzt funktioniert ist da, beim Mbus muss ich ebenfalls über Javascript den Logger auswerten und in States umwandeln, wenn ich jetzt noch was für Bacnet fertig bekomme (KNX ist schon scheisse, aber Bacnet haut nochmal ein paar Schippen drauf....) dann ist die GLT fertig! :D

Mich würde aber trotzdem die Funktionsweise der Datenpunktpaare (DPP) brennend interessieren um ggf. Ungereimtheiten beim Import die technisch eben aufgrund der schlecht zu wrappenden knxproj Datei auftreten können manuell zu verbinden...

Zum Thema Hauptgruppen und Routingprobeme der Koppler, ich habe in Summe 14 Hauptgruppen, Mittelgruppen sind immer die Stockwerke. Ältere Koppler wollen nur bis 15, neuere können bis zu 30 Hauptgruppen. Diese extrem gestreckte Struktur ist aber wirklich nur sinnvoll bei einem größeren Objekt um zu jeder "schalten GA" ein Paar mit derselben Mittelgruppe und Gruppenadresse für RM, Wert usw. zu haben. Hätte auch auf Mittelgruppe verzichten können und auf zweistufige Struktur mit 2048 GAs pro Hauptgruppe setzen können mit diversen Bereichen, so finde ich es aber am überschaubarsten.

[Videonisse]

@RESDE A curious question about the Problem for @AlexW85; was the issue that "Ein/Aus" had to be replaced with "Schalten"?

I thought the issue was that he was using "/" in the names. From the Readme: Vermeidung von Sonderzeichen ",./;&%$§[]" When I replaced "Av/På" with "Av-På" (it's Swedish), the project import started to run just fine, including the Switch-Status Pairs (DPP).

@teddysdl Maybe this issue also could be closed now?

[AlexW85]

Trotz aller Bemühungen gibt es immer noch sehr viel Handarbeit! In größeren Projekten wo Räume nur Raumnummern sind, Büro1 und Büro2 heißen und man auch den Text kurz halten möchte kommt man mit den 90% nicht immer hin. Ein weiteres Problem sind Dimmwerte wo es Absolut und Relativ GAs gibt (Relativ interessiert mich in der Visu nicht, aber er importiert es ja mit und versuchts zu wrappen) und die motorischen Antriebe (Fenster/Markisen/Rollos usw) die teilweise Positionsrückmeldungen geben, oder Endlage oben/Endlage unten rückmelden (je nach Aktor oder Einsatz) sind sehr problematisch. Hinzu kommt der Stop/Verstellen Befehl der ja erstmal keine Rückmeldung hat. Ohne Rückmeldung setzt der Adapter wahllos Flags die nicht nachvollziehbar sind. Man ist am Ende echt länger beschäftigt alles auszubessern als von vorneherein alles von Hand anzulegen. Und wenn man das nach Ewigkeiten mal durch hat kann man dann erst mit der Visu beginnen. Bei jeder Änderung muss dann auch noch der Adapter neu gestartet werden und zieht sich erstmal alle ~ 800 Rückmeldungen rein bis man was machen kann.

Ich bin froh das es einen Adapter gibt und es ist schön das ich ein ETS Projekt direkt importieren kann. Aber wenn aus den neueren ETS Versionen halt nur Müll rauskommt, dann muss ich es eben händisch verknüpfen. Iobroker Admin ist da aber echt nicht geeignet dies annähernd übersichtlich, schnell und komfortabel durchzuführen. Für Zuhause mit 10 Aktoren ist das alles sicherlich super und schnell gemacht, da der Adapter für Unternehmen Geld kostet werde ich ihn aber so nicht implementieren, sondern wieder was mit Javascript zusammenbasteln was dann auf meine Struktur passt und auch die Räume (die ja importiert aber nicht verknüpft werden) zuweist. Auch Rückmeldungen beim Start lesen ist sehr unschön, macht kaum ein Touchpanel im KNX, initiales lesen auf Anforderung ist ok, aber nicht mit jedem Start des Dienstes!

Jetzt kann es geschlossen werden! 😊