Test Adapter KNX v1.0.x

[loverz]

@lessthanmore Hab nun meine ganzen Objekte händisch korrigiert.
Also:
-Statusobjekte mit Write=false und Read=true
-Schaltobjekte mit Write=true und Read=false

Nach dem Updaten auf die aktuellste Version des KNX Adapters bekomme ich direkt wieder keine Rollo-Positionen, wenn diese gefahren sind.

Muss wohl wieder auf 1.0.20 runter...

[lessthanmore]

@loverz StatusGA müsste glaube ich beides true sein, also write und read. Nur dann reagiert der Adapter auf ein GroupValueRead.
Warum hast du nicht erst ein Update gemacht?
Die Verknüpfung zwischen Schalt und Status DP wurde ja erst nach 1.0.20 eingeführt.
Hast du in deinen Skripten wirklich so oft die Statusadresse verwendet? Oder eher die Schaltadresse?
Denn du müsstest in der ETS ja nur die Status GA umbenennen.
Dann Update vom Adapter und Projekt neu importieren damit alles sauber angelegt wird.

[loverz]

@lessthanmore ich habe erst die Objekte händisch angepasst, weil ich wusste, dass der Adapter Probleme macht. Hab es nun bestimmt schon 4 mal veruscht upzudaten.

Ich habe in meinen Scripten alle möglichen Objekte verwendet, ich will da nicht nochmal ran, die laufen einwandfrei.

Nun werde ich bei den Status Adressen noch zusätzlich den Write auf True setzen und die letzte Chance geben....

[lessthanmore]

@loverz Ich glaube wir drehen uns im Kreis.
Probier es, aber weitere Probleme sind dann recht wahrscheinlich bzw. können nicht ausgeschlossen werden.

[mpenno]

@loverz
Ich versuche mal zu helfen. Bei mir klappt es recht gut.
Ich nutze:

• KNX-Adapter: 1.0.45
• ETS-Version: 5.7.4

Meine Jalousie im Badezimmer wird von einem ABB JAL-Aktor angetrieben. Befehle wie auf und ab gehen, sowie die direkte Positionsansteuerung. Bei der Badezimmerjalousie nutzte ich ausschließlich die Positionsansteuerung über ioBroker und der ioGO-App.
Die Schaltgruppenadresse:

Die zugehörige Statusgruppenadresse:

Die KNX-Objekte am Aktor:

Das KNX-Schaltobjekt im ioBroker:

Die Objekt-Eigenschaften der Schaltadresse:

{
  "_id": "knx.0.Jalousie.Jalousie_Position.Jalousie_Position_Badezimmer",
  "type": "state",
  "common": {
    "name": "Jalousie Position Badezimmer",
    "type": "number",
    "role": "value",
    "unit": "%",
    "max": 100,
    "min": 0,
    "read": false,
    "write": true
  },
  "native": {
    "dpt": "DPT5.001",
    "address": "2/1/205",
    "addressRefId": "P-02CE-0_GA-376",
    "statusGARefId": "P-02CE-0_GA-377",
    "actGARefId": "",
    "objRef": "O-13_R-1388",
    "devName": "M-0002_A-A064-14-83B7",
    "devInst": "P-02CE-0_DI-56",
    "objectSize": "",
    "update": false
  },
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1603985491838,
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  }
}

Das KNX-Statusobjekt im ioBroker:

Die Objekt-Eigenschaften der Statusadresse:

{
  "_id": "knx.0.Jalousie.Jalousie_Position_Status.Jalousie_Position_Badezimmer_Status",
  "type": "state",
  "common": {
    "name": "Jalousie Position Badezimmer Status",
    "type": "number",
    "role": "value",
    "unit": "%",
    "max": 100,
    "min": 0,
    "read": true,
    "write": false
  },
  "native": {
    "dpt": "DPT5.001",
    "address": "2/2/205",
    "addressRefId": "P-02CE-0_GA-377",
    "statusGARefId": "",
    "actGARefId": "P-02CE-0_GA-376",
    "objRef": "O-33_R-1407",
    "devName": "M-0002_A-A064-14-83B7",
    "devInst": "P-02CE-0_DI-56",
    "objectSize": ""
  },
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1603985491844,
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  }
}

Das Alias-Objekt, mit denen ich seit einer Weile ausschließlich arbeite. Es reicht dieses eine Aliasobjekt auf die Schaltadresse. Ein Alias auf die Statusadresse ist nicht notwendig:

Die Objekt-Eigenschaften des Alias-Objektes:

{
  "type": "state",
  "common": {
    "name": "Rollladen",
    "type": "number",
    "role": "level.blind",
    "unit": "%",
    "max": "100",
    "min": "0",
    "read": false,
    "write": true,
    "alias": {
      "id": "knx.0.Jalousie.Jalousie_Position.Jalousie_Position_Badezimmer",
      "read": "val*1",
      "write": ""
    },
    "desc": "Geziehlte Position anfahren",
    "states": "",
    "custom": []
  },
  "native": {},
  "from": "system.adapter.javascript.0",
  "user": "system.user.admin",
  "ts": 1603996490851,
  "_id": "alias.0.Rollladen.Raum_203_Badezimmer.Rollladen_Position",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Hier mal die Steuerung mittels der Android App ioGO:

Wichtig ist, dass wenn du die ioBroker-Objekteigenschaften änderst, musst Du den KNX-Adapter neustarten. War zumindestens bei mir so.

Es sollte keinen Grund geben, dass es bei Dir nicht so klappt. Auch wenn Du die Aliase nicht nutzt. Dann würdest Du direkt mit dem Schaltobjekt arbeiten.

Du solltest aber zukünftig die Aliase nutzen, damit Du nicht die festen Objektadressen in den Scripten nutzt. Das Anlegen der Aliase macht kurz etwas Arbeit. Ich nutze dazu pro Gerät ein Script, damit ich nicht soviel klicken muss.

Bei mir geht mit dem KNX-Adapter fast alles. Nach einem anfänglichen Geisterhaus beim Starten des KNX-Adapters, wo viel an und aus bzw. Rollläden hoch- und runter fuhren, musste ich nur die KNX-Flags in Ordnung bringen und auf die richtige Verbindung zwischen Schalt- und Status-GA im ioBroker sorgen (siehe meinen Vorrednern). Das geht zum Teil automatisch beim Einlesen, nur ganz selten musste ich es manuell korrigieren.

Nur mit Datum und Zeitobjekten will es bei mir zwischen ioBroker und KNX nicht so richtig. Falls mir da jemand weiterhelfen kann. Zum Beispiel welcher Objekttyp: String, Number oder Mixed der richtige ist...

Viele Grüße
Michael

[loverz]

@mpenno danke für ausführliche Erklärung.

Die Positionsansteuerung funktioniert bei mir einwandfrei, nur die Positionen, welche von KNX nach iobroker gehen sollen kommen nicht an.

Die Flags der Objekte sind so wie bei dir: Schalt-Objekte Write=True; Read=False. Status-Objekte Write=False; Read=True.

Der einzige Unterschied scheint meine Benennung in ETS zu sein:
Wohnzimmer_Rollladen_Nord_Position_anfahren
Wohnzimmer_Rollladen_Nord_Position

Ich hab also die Benennung von der Schalt-GA nicht zu 100% im Namen von der Status-GA. Daran kann es aber doch nicht liegen mensch

Mich ärgert es, dass doch beim 1.0.20 alles geht und danach nicht mehr!

Die Alias-Objekt hast du nur gemacht um zukünftige Umbenennungen einfacher zu gestalten, habe ich das richtig verstanden?

[lessthanmore]

@loverz said in Test Adapter KNX v1.0.x:

Wohnzimmer_Rollladen_Nord_Position_anfahren

Dann ändere nur einmal diese GA zu:
Wohnzimmer_Rollladen_Nord_Position_anfahren_Status

und du wirst ein Wunder erleben

Kannst sie ja mal zu Testzwecken umbenennen. Nur daran liegt es nämlich.
Es geht ja nach Version 1.0.20 nicht nur um die Eigenschaften read und write, sondern auch um die Pärchen, also
addressRefId
statusGARefId
actGARefId

Das gilt es eben händisch anzupassen wenn man die GA in der ETS nicht umbenennen möchte/ kann.

[loverz]

@lessthanmore also doch. Es liegt echt am Namen... Das ist aber ehrlich gesagt sehr doof gemacht vom Adapter...

Ich werde testweise mal ein Pärchen und die dazugehörigen Scripte umbenennen und mich anschließend nochmal melden.

Aber wenn dann muss ich doch die andere GA
Wohnzimmer_Rollladen_Nord_Position umbenennen in:
Wohnzimmer_Rollladen_Nord_Position_anfahren_Status oder nicht?

[lessthanmore]

@loverz Ja, richtig. Hatte die falsche GA zitiert.
anfahren ist die Schalt GA und anfahren_Status die Status GA.
Wie soll der Adapter denn erkennen dass die beiden zusammen gehören wenn sie nicht gleich heißen bzw. identisch sind?
Der Adapter kennt lediglich die Adresse, Bezeichnung und die Flags.
Nach welcher Logik würdest du es denn machen?
Wie gesagt, diese Abfrage kam erst nach 1.0.20 weshalb es bei Versionen vorher bei dir keine Probleme gab.

[loverz]

@lessthanmore der Adapter muss das doch gar nicht wissen, ob die zusammen gehören, das ist doch der Punkt! 1.0.20 weiß das auch nicht.

Der Adapter soll einfach nur dafür sorgen, dass wenn mein Rollladen Aktor auf die Status GA einen Wert (z.B.100%) sendet dies im entsprechenden iobroker Objekt eingetragen wird, das kann doch nicht so schwer sein.

[lessthanmore]

@loverz Was soll ich dir sagen?
Die Änderung wurde aber implementiert um sie später für weitere Funktionen nutzen zu können.
Zumindest war das wohl mal der Plan.
Nach 1.0.20 prüft der Adapter eben auf Pärchen. Ist so.
Das kann man jetzt doof finden oder nicht, aber es wird sich nicht ändern.
Also benennt man entweder seine Gruppenadressen einmalig sauber in der ETS (RM, Status, etc.) oder man muss alles händisch anpassen.
Oder aber man nutzt weiterhin die 1.0.20 und bleibt auf einer veralteten ETS hängen.

Im Übrigen steckt im Adapter ein bißchen mehr Logik als simples „Shit in, shit out“.
Wenn du nur einen Wert auf den Bus senden willst und einen lesen möchtest tut es eben auch node-red.

[Tobi68]

@loverz sagte in Test Adapter KNX v1.0.x:

@lessthanmore der Adapter muss das doch gar nicht wissen, ob die zusammen gehören, das ist doch der Punkt! 1.0.20 weiß das auch nicht.

Der Adapter soll einfach nur dafür sorgen, dass wenn mein Rollladen Aktor auf die Status GA einen Wert (z.B.100%) sendet dies im entsprechenden iobroker Objekt eingetragen wird, das kann doch nicht so schwer sein.

Äh..
Der Adapter hätte gerne das die zugehörige GAs einen logische Benennung haben..
Mal ganz simpel:

Rolladen EG Wohnzimmer rauf
Rolladen EG Wohnzimmer runter
Rolladen EG Wohnzimmer status
Rolladen EG Wohnzimmer Teil

So ist er programmiert.
Wenn du es gerne anderst hättest brauchst du einen anderen Adapter

Musste ich auch lernen und halt nach richten..
Es ist halt ne ETS für die Umbenennung sinnvoll..

Oder kippst du in deinen Benziner auch ab und zu Diesel..

[loverz]

@lessthanmore @Tobi68 alles klar, ich glaub ich bin einfach nicht fähig die Logik zu verstehen.
Das einzige was ich verstanden habe: Es wurde eine neue Funktion implementiert, die man wahrscheinlich in der Zukunft brauchen könnte, dann ist der Entwickler aber weg gegangen. Da es wahrscheinlich nicht mehr weitergehen wird, kann ich auch auf 1.0.20 bleiben, da diese neue Funktionen wohl nie kommen werden.

Was ich aber nochmal fragen muss:
"Entweder man benennt im ETS alles sauber um, oder muss selbst Hand anlegen"
Dieses selbst Hand anlegen beinhaltet das Bearbeiten der RAW-Werte richtig? Ich frage mich nur, wie ich dem Adapter über die RAW-Werte erklären kann, welche Pärchen nun zusammengehören.
Sorry, ich stehe etwas auf dem Schlauch...

[lessthanmore]

@loverz Ich wiederhole mich, aber wir drehen uns im Kreis.

Bis 1.0.20 wurde jede GA einzeln betrachtet und gemäß den Flags in ETS angelegt und deren Attribute entsprechend gesetzt.

Mit 1.0.30 wurden dann erweiterte Statusobjekte (actRefId, etc.) verwendet, um die Funktionen zu erweitern. In erster Linie um im Adapter zu wissen, wenn eine Status GA bspw. eine Rückmeldung erhält, von welchem Schaltobjekt diese Rückmeldung kommt.

Evtl. hatte es damit etwas zu tun, ist aber alles nur Mutmaßung.

Bis 1.0.20: Es müssen die Attribute der Datenobjekte (RAW) manuell angepasst werden, so fern sie nicht korrekt gemäß der Flags angelegt wurden (write und read).
Ab 1.0.30: Gleiches wie oben + die jeweiligen Schalt und Status Datenpunkte müssen miteinander verbunden werden.

Schau dir die Screenshots von @Tobi68 an. Dort siehst du für jeden Datenpunkt die zusätzlichen Attribute adressRefId, statusGARefId und actGARefId. Wenn du die Werte betrachtest, dann siehst du, dass diese in den jeweiligen Datenpunkten verknüpft sind.
addressRefId ist die eindeutige ID pro GA.
Im Schaltdatenpunkt befindet sich die entsprechende addressRefId des Statusdatenpunktes im Feld statusGARefId.
Im Statusdatenpunkt befindet sich die entsprechende addressRefId des Schaltdatenpunktes im Feld actGARefId.

Die Zeit, die wir hier diskutieren, hättest du übrigens wunderbar verwenden können, um die Gruppenadressen in der GA umzubenennen und die ersten Skripte anzupassen

Wie gesagt, klar kannst du auf der 1.0.20 bleiben. Wenn die bei dir sauber läuft warum auch nicht.
Möchtest du allerdings auf eine neuer ETS Version und machst Änderungen in der ETS, die du dann in den Adapter übertragen möchtest, so geht das nicht mehr.
Selbst mit der aktuellsten Adapter Version ist ein Import der ETS Version 5.7.6 bereits nicht mehr möglich.
Jetzt können wir natürlich auch gerne noch darüber diskutieren, ob es sinnvoll ist oder nicht die ETS Version aktuelle zu halten, aber das würde dann wohl den Rahmen sprengen.
Gleiches gilt auch für deine nodejs Version

Was wenn Kay in nächster Zeit am Adapter weitermacht? Oder ein anderer Entwickler warum auch immer übernimmt? Dann musst du den Schritt eh gehen. Aber mehr als spekulieren können wir nicht.

[Tobi68]

@loverz :

Meines Wissens ist der Entwickler nicht weggegangen..
Der wartet auf die neue ETS, oder würdest du auch noch ETS3 Sachen supporten.. alles in der Freizeit?

[Tobi68]

@lessthanmore sagte in Test Adapter KNX v1.0.x:

Die Zeit, die wir hier diskutieren, hättest du übrigens wunderbar verwenden können, um die Gruppenadressen in der GA umzubenennen und die ersten Skripte anzupassen

Der war gut!
War auch für mich ne harte Schule, aber so verliert Mann als Einsteiger die Scheu vor der ETS..

[loverz]

@lessthanmore alles klar, danke mal
Ich warte ob der Entwickler zurückkehrt und mache mich dann ggf. an die Arbeit.

Der einzige Nachteil von 1.0.20 für mich ist, dass die Objekte mit 1/0 statt true/false beschrieben werden, das äußert sich aber nur mit Hinweisen im log, also verkraftbar

[loverz]

@lessthanmore ich hab mir eben mal die Programmierung von meinem Kumpel angeschaut. Er hat auch iobroker mit KNX, eigentlich genau wie ich.
Die Gruppenadressen sind nach exakt dem gleichen Schema wie bei mir programmiert:
Wohnzimmer_Jalousie_Position_anfahren
Wohnzimmer_Jalousie_Position

Komischerweise funktioniert bei ihm alles mit dem neuesten Adapter, die Positionen der Rollläden passen nach der Fahrt.

Ich kann mir das nicht erklären, vor allem widerspricht das doch deiner Aussage bezüglich der Pärchen, die gefunden werden müssen

Irgendwie ist bei meinem iobroker der Wurm drin

[lessthanmore]

@loverz Das Schema mag zwar stimmen, aber entweder die Adressen bei deinem Kumpel sind richtig mit dem Status oder RM - Zusatz (im Gegensatz zu deinen) oder er hat händisch nachgearbeitet.
Schick doch mal einen Screenshot seiner GA beispielhaft.
Meine Adressen sind auch nach diesem Schema, aber haben ein „RM“ am Ende für den Status, das reicht dem Adapter eben auch schon.

Glaub es doch einfach und teste es selbst.
Ändere deine GA Bezeichnung zu Testzwecken.

Andere und ich haben dir das jetzt mehrfach bestätigt.
Nochmal - und letztmals von mir - ändere die GA oder bleib auf 1.0.20.
Vom Diskutieren ändert sich das Verhalten - zumindest das des Adapters - definitiv nicht.

Bzgl. deines ioBrokers sieht man ja auch im Zigbee Thread dass updaten nicht gerade deine Sache ist. Updates machen aber durchaus Sinn

[loverz]

@lessthanmore ich bin einfach offensichtlich ein totaler Noob was das hier alles angeht Schade.