Test Adapter KNX v1.0.x

[loverz]

also ich hab mir nun mal meine RAW-Werte für die vom KNX Adapter erstellten Objekte angeschaut und ich muss sagen: Katastrophe!

Keine Ahnung, nach welchem Schema die Objekte erstellt werden, aber oft sind bei Schalt-Adressen Read/Write = false, oder bei Status Adressen der Read-Wert = false, oder mal sind gar keine Read/Write Werte vorhanden...

Hab jetzt weitgehend mal händisch geändert was ich konnte.

Ich meine ich bin ja froh, dass KNX überhaupt funktioniert, aber professionell ist das nicht, eher eine Bastellösung...

[lessthanmore]

@loverz Ich hatte das ja bereits in einem anderen Thread mal erklärt und auch diskutiert.
Vorab: Ich habe mit dem Adapter nichts zu tun und nutze ihn auch nicht mehr; ich bin auf node-red zusammen mit node-red-contrib-knx-ultimate umgestiegen.
Da mein Haus durch knx zu 80-90% automatisiert ist benötige ich lediglich 10-15 Gruppenadressen im ioBroker und die habe ich einfach händisch angelegt.

Nun zu "deiner" Katastrophe:
Um es mit chefkochs Worten zu sagen "Deine Gruppenadressen sind nicht sauber programmiert".

Unter sauberer Programmierung aka "Best Practice" im knx gehört es, dass zu jeder Schaltadresse auch eine Statusadresse definiert wird.
Der Adapter (wie jedes Programm) benötigt eine Logik. Gibt es diese Logik nicht, so kann der Adapter die Gruppenadressen bzw. Datenpunkt eben nicht korrekt anlegen.
Was bedeutet das konkret?
Der Adapter prüft die Flags der Gruppenadressen, um herauszufinden, ob die GA schaltbar ist oder nicht.
Im zweiten Schritt - sofern eine Schaltadresse gefunden wurde - sucht der Adapter nach seinem Pärchen, sprich der Statusadresse. Findet er diese nicht, so weist er der Schaltadresse write=true und read=true zu.

"Saubere Programmierung": Wie gesagt, kommt nicht von mir, sondern steht so in der Anleitung für den Adapter.
Wenn du bspw. eine GA hast: "Büro Deckenlicht Schalten", dann sollte deine dazugehörige Status-GA "Büro Deckenlicht Schalten Status" oder "Büro Deckenlicht Schalten RM" oder "Büro Deckenlicht Status Schalten" heißen.
Ist das bei dir der Fall?

Wenn nicht liegt genau dort der Grund, warum der Adapter - in deinen Augen - die Datenpunkte falsch anlegt. ABER, der Adapter macht alles richtig, bzw. genau das, was er soll. Nur wenn eindeutig ein Pärchen gefunden wird, werden die beiden Datenpunkte über ActRef, etc. verbunden bzw. miteinander verlinkt.

Vorschlag: Benenn deine Gruppenadressen nach oben genannten Schema um. Es ist nur der Name der GA und hat keinerlei Auswirkung auf die Gruppenadressen oder die Kommunikationsobjekte. Es muss nichts neu programmiert werden, etc.
Wenn du bspw. GA hast, die gar keinen Status haben, weil bspw. der Aktor keinen Status zurückgibt, so kannst du dennoch eine "leere" GA in der ETS anlegen, so dass der Adapter die eigentliche Schaltadresse auch richtig erkennt.

Sorry für den langen Text. Wie erwähnt, auch ich finde es nicht schön und hätte den Adapter gerne weiterverwendet.

[cvidal]

@lessthanmore Ja Traum, hab Write auf True gesetzt und Read auf false, Lief direkt. Besten dank euch allen.

Hab noch mal ne frage bzgl. Position Anzeigen.
Ich habe die Objekte "Position anzeigen" und "Position anfahren"
Wenn ich Manuell meine Rollladen fahre bekomme ich den % Wert nur auf "Position anzeigen" und nicht auf "Position anfahren".
Ich brauche den aktuellen Wert im Objekt "Position anfahren" um den Shuttercontrol Adapter nutzen zu können. Bekomme ich das ohne ETS hin?

Gruß Christian

[loverz]

@lessthanmore du hat Recht, ich möchte dem Entwickler auch nicht zu nahe treten, im Gegenteil: Ich bin dankbar!

Dass bei dir „nur“ 15% über iobroker läuft ist dein Glück, bei mir ist es der Kehrwert: 85%: Mein Pech!

Das mit der Korrekten Benennung der Gruppenadressen ist logisch, aber keinesfalls einzig wahre best Practise.
Wenn ich meine GAs wie folgt anlege:
-Wohnzimmer schalten
-Wohnzimmer Status
dann ist das definitiv noch im Rahmen der ETS Empfehlung. Der Adapter kommt damit allerdings nicht klar.

Umbenennen ist nicht so einfach wie du beschreibst, da dann auch sämtliche Java Scripte angepasst werden müssen, das ist auch der Grund was mich davon abhält.

Mit Bastellösung meine ich eigentlich, dass sowas aus meiner Sicht nicht passieren darf/sollte, dass alles stirbt, wenn sich eine Person zurückzieht.

Wenn ich das gewusst hätte, wäre ich lieber auf ein anderes System gegangen, welches da mehr Zuverlässigkeit bietet, auch wenn es etwas kostet.

[lessthanmore]

@cvidal Ich gehe davon aus, dass dein Aktor nur auf "Position anzeigen" zurückmeldet. Ist bei mir glaube ich genauso.
Wenn du den Rollladen manuell bedienst, dann setzt du ja keine Position, sondern fährst auf oder ab und stoppst. Die Position wird dann zurück gemeldet.

Wird in shuttercontrol nicht auch nur die Position rückgemeldet oder muss das der gleiche Datenpunkt sein?

autoLevel zeigt die Position an, aber es kann nicht über diesen DP gesteuert werden.
Kenne mich mit shuttercontrol nicht aus. Habe meinen Sonnenschutz komplett im knx über Wetterstation, etc. laufen/ implementiert.
Evtl. mal im anderen Thread direkt fragen. Gibt denke ich mehrere, die das zusammen mit knx nutzen und die Schaltadresse darf nie die Rückmeldeadresse sein.

[lessthanmore]

@loverz Über wie viele Geräte bzw. Gruppenadressen reden wir denn?
Wie gesagt, ein langes Wochenende und du hast das selbst in node-red gemacht und bist unabhängig vom Adapter.
Bzgl. Best Practice gebe ich dir natürlich recht. Habe ja darauf hingewiesen, dass das nicht von mir kommt, sondern in der Anleitung des Adapters steht.
Mach es halt Stück für Stück - Raum für Raum - Etage für Etage. Jedes Wochenende ein bißchen, irgendwann hast du es dann.
Kannst auf die aktuelle ETS hoch und wahrscheinlich sogar auf die ETS6, sobald die rauskommt.

Darf ich fragen, warum bei dir ca. 85% im ioBroker laufen (müssen) oder geht es auch um die Einbindung von non-knx Geräten?

So sieht es bei mir momentan aus:

Ist keine Raketenwissenschaft. Und da ich mit Entwicklung bzw. Programmieren null am Hut habe, nutze ich weiterhin Blockly für die Logik, obwohl ich es direkt in node-red machen könnte bzw. jeder andere der entwickeln kann.

Evtl. lässt sich auch @Garfonso für einen kleinen proof of concept gewinnen.

Grundsätzlich dürfte das exportieren der Gruppenadressen und das anlegen selbiger als Datenpunkte im ioBroker kein Hexenwerk sein. Mit Hilfe der nodes kann dann der jeweilige Befehl (Gruppenadresse ist ja bekannt) auch über den Global Context node gesendet werden.

[loverz]

@lessthanmore ich denke nicht, dass ich die ETS Programmierung UND meine Scripte an einem langen WE schaffe. Ich habe wirklich extrem viele Logikscripte. Keine Ahnung, aber ich schätze über 300. Das ist auch der Grund wieso ich 85% in iobroker habe, weil der einfach viel mehr kann als die KNX Aktoren. Hab keinen KNX Logikserver!

Mit NodeRed habe ich nie gearbeitet, müsste mich da komplett einlesen. Verstehe ich richtig, dass NodeRed direkt mit KNX kommunizieren kann?

[loverz]

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

@lessthanmore Ja Traum, hab Write auf True gesetzt und Read auf false, Lief direkt. Besten dank euch allen.

Hab noch mal ne frage bzgl. Position Anzeigen.
Ich habe die Objekte "Position anzeigen" und "Position anfahren"
Wenn ich Manuell meine Rollladen fahre bekomme ich den % Wert nur auf "Position anzeigen" und nicht auf "Position anfahren".
Ich brauche den aktuellen Wert im Objekt "Position anfahren" um den Shuttercontrol Adapter nutzen zu können. Bekomme ich das ohne ETS hin?

Gruß Christian

Ich hab dafür ein Blockly gemacht, welches nach dem fahren Position anfahren mit dem Wert von Position AKTUALISIERT, nicht steuert, dann sind beide Werte synchron. Das braucht man auch für YAHKA (Apple homekit) so.

[lessthanmore]

@loverz Ich habe auch keinen Logikbaustein und nutze auch die Logik nicht, die mit vielen Geräten bereits mitkommt. Die Logik in der KNX ist wirklich viel zu schwach, kennt nur UND und ODER.
Aber du kannst auch verdammt viel mit Szenen machen. Meine Rollläden bspw. laufen alle über Szenen.
Ich habe dafür nur eine einzige GA, auf die ich lediglich eine Szenennummer schicke und die Rollläden dementsprechend fahren.
Sonnenschutz lässt sich auch prima mit den Aktoren von MDT umsetzen und die kosten nicht viel.

Mir ist vor allem wichtig so viel wie möglich in der KNX laufen zu haben um unabhängig vom ioBroker zu sein; siehe KNX Adapter. Es kann immer mal sein, dass ein Entwickler keine Lust mehr hat oder schlimmeres passiert.

Lichter kann man auch super über Szenen steuern und die meisten Aktoren bringen das mit (DALI bspw.).
Und selbst wenn du die Logik im Skript in ioBroker hast, so musst du von ioBroker lediglich eine GA mit einer Szene beschreiben, etc.

Ich habe mir node-red erstmals vor genau zwei Tagen installiert. Für node-red werden unzählige Module angeboten und für knx gibt es mehrere (ultimate, easy, etc.).
Im Modul selbst hinterlegst du lediglich die IP Adresse deines Gateways oder Router:

Du verlinkst dann einen Datenpunkt aus ioBroker mit einer GA und der Wert von ioBroker wird direkt auf die GA geschrieben. Beim Update aus KNX kommend sollte man allerdings darauf achten, dass ioBroker, der den Wert aktualisiert, nicht direkt wieder an den Bus schickt. Hatte ich hübsche Disko hier im Haus weil alles an/ aus, usw. gegangen ist

Aber wenn du wirklich über 300 Gruppenadressen hast, dann ist das schon eine Hausnummer und dann verstehe ich das auch.

[loverz]

@lessthanmore danke für den kleinen Gedankenausflug

Hab auch die MDT Aktoren, aber nie die Szenen verwendet.

Ich verfolge einen anderen Denkansatz:
-KNX für Grundfunktionen, sodass auch ohne iobroker alles manuell funktioniert.
-iobroker für die Automationen bzw. Logiken. Natürlich mache ich mach da ein Stückweit abhängig, aber wenn mal alles läuft muss ich ja nicht updaten. Ist ja alles Offline, das relativiert alles ein wenig.

[lessthanmore]

@loverz Ja, da bin ich ganz bei dir.
Wenn du node-red mal ausprobieren willst und Fragen hast, schreib mich einfach an. Hier geht es ja um den KNX Adapter.

Im Übrigen kannst du mit dem ultimate Modul auch deine Gruppenadressen importieren. Aber es ist natürlich deutlich mehr Arbeit als mit dem Adapter, der schon alle Datenpunkte anlegt.

[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.