Test Adapter KNX v1.0.x

[Merlin123]

Die 1.0.36 läuft bei mir ohne Probleme. Zumindest ist mir nix aufgefallen

[Garfonso]

Hi,

ich kann mit 1.0.36 mein Projekt nicht mehr importieren, es gibt einen TypeError:

2019-11-03 19:17:34.243  - debug: knx.0 (24954) knx.js Time fillProject start.
2019-11-03 19:17:34.487  - warn: knx.0 (24954) States pmessage io.messagebox.system.adapter.knx.0 {"command":"projectFinished","message":null,"from":"system.adapter.admin.0","callback":{"message":null,"id":188,"ack":false,"time":1572805054188},"_id":76582467} Cannot read property 'range' of undefined
2019-11-03 19:17:34.489  - warn: knx.0 (24954) TypeError: Cannot read property 'range' of undefined
    at _0x3d0a60 (/opt/iobroker/node_modules/iobroker.knx/knx.js:44:13773)
    at _0x486492 (/opt/iobroker/node_modules/iobroker.knx/knx.js:44:15343)
    at Object._0x228177 [as convertAll] (/opt/iobroker/node_modules/iobroker.knx/knx.js:44:40114)
    at Object.getGAS (/opt/iobroker/node_modules/iobroker.knx/knx.js:72:13770)
    at _0x601f89 (/opt/iobroker/node_modules/iobroker.knx/knx.js:80:8157)
    at Adapter.<anonymous> (/opt/iobroker/node_modules/iobroker.knx/knx.js:80:6848)
    at Adapter.emit (events.js:198:13)
    at change (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:4717:34)
    at Immediate.setImmediate [as _onImmediate] (/opt/iobroker/node_modules/iobroker.js-controller/lib/states/statesInRedis.js:223:41)
    at runCallback (timers.js:705:18)

ETS ist 5.7.2.
Ich bin jetzt Versionen einzeln zurück gegangen. Mit Version 1.0.31 geht der Import. Ich habe auch ein issue auf github erstellt, damit das nicht verloren geht: https://github.com/ioBroker/ioBroker.knx/issues/77
Wenn du das Projektfile brauchst, kann ich das gerne irgendwie schicken oder so.

[killroy2]

@Merlin123 Vielleicht liegts an der Anzahl der Daten. Ich habe eine mittlere Installation mit 500 GA.

[Garfonso]

@killroy2
Also ich bin bei knapp 700 GA und abgesehen vom Import Problem tut bei mir die 1.0.36 auch problemlos ihren Dienst. Zur 1.0.35 kann ich keinen Unterschied feststellen.

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

Die Flags beziehen sich doch lediglich auf ein KO. Ein korrespondierendes KO mit der GA hat die Flags ganz anderst gesetzt. Ich verstehe deshalb nicht wie die Logik bei verbundenen GA's funktioniert. Oder nimmst du an, dass alle Kommunikationsbeziehungen zum IOBroker über eigene GAs laufen

Nein, eigene GAs für den ioBroker werden nicht angenommen. Eher im Gegenteil, das ist, finde ich, etwas fummelig und z.B. ein StatusGA aus dem ioBroker lesen geht bei mir immer noch nicht (ich habe ein paar Taster so umgebaut, dass der Befehl vom ioBroker im KNX empfangen wird und dann mit zigbee oder so ausgeführt wird).
Der beste Tipp hier ist: Befehls GA und Status GA sollten im Namen identisch sein bis auf ein "Status" was bei der Status GA hinzugefügt wird. Dann erkennt der Adapter die Pärchen recht gut, selbst wenn die Flags nicht ganz sauber sind. So meine Erfahrung. Und dann macht's auch Spaß.

[killroy2]

Hier mal als Beispiel mein Jalousiekator. Der Befehl Rolladen Auf/Ab hat zwei Stati: Verfahrstatus Auf und Verfahrstatus Ab. Da lässt keine 1:1 Beziehung herstellen.

Der Importer hat eine konzeptionelle Schwäche und kann bei mir nie richtig funktionieren. Besser wäre es der Empfehlung der KNX Associaction zu folgen und die Heimautomatisierung als eigenes Gerät in der ETS auftauchen zu lassen. Dann sind die Kommunikationsbeziehungen an einem Ort gehalten mit den dafür vorgesehenen Methoden und man braucht keine Verknüpfungen z.B. versteckt über Namensregeln.

Ich habe den Import einmal von Hand korrigiert. Bei jedem Reimport mache ich einen Diff mit der alten Config und rette die Einstellungen rüber. Das ist umständlich aber besser gehts nicht.

[nightstore]

@killroy2 bin momentan wieder zurück (1.0.20) das passt soweit. ist ein downgrade der ETS möglich?

[Garfonso]

@killroy2
Ja, das ist richtig für den Rolladenaktor ist die ActGA / StatusGA Beziehung nicht 1:1. Wobei meiner etwas anders ist, ich kann den mit % fahren und dafür gibt es auch einen Status GA.

Der Vorteil der aktuellen Situation ist mE, dass der ioBroker so alle Schaltvorgänge auf dem KNX Bus mitbekommt. Das wäre, wenn er ein eigens Dummy Gerät wäre, ja nicht der Fall. Im Grunde müsste man dann ja für jeden Befehl eigene GAs zum ioBroker anlegen... das wäre in meinem Setup deutlich aufwendiger als die aktuelle Variante.

Der Import könnte besser geregelt sein, da gebe ich dir recht. Das steht auch schon lange auf der Liste. Ein bisschen problematisch ist, dass der Sourcecode vom KNX Adapter nicht wirklich offen ist und daher chefkoch alles alleine machen muss... ansonsten könnte da ja auch jemand aus der Community einen Vorschlang entwicklen, wie es ggf. besser ginge.

Gegen das von Hand korrigieren sollte doch helfen den "nur neue Objekte hinzufügen" haken zu drücken, oder? Wobei ich mittlerweile umfangreiche Skripte geschrieben habe und nur noch das wenigste auf den KNX-Objekten selber arbeitet (z.B. für shutter die grundsätzlich per % angefahren werden aber 0% und 100% in hoch/runter übersetzen, da sonst die Shutter nicht ganz sauber nach oben/unten fahren, da der Aktuator nur in Sekundenschritten steuert). Wenn ich es richtig im Kopf habe ist es dem javascript Adapter egal, ob der State schreibbar ist oder nicht, das schreiben geht trotzdem.

[killroy2]

Ich sehe die Objekte werden aktualisiert egal ob ich "Lesen erlaubt" Flag setze oder nicht. Ich würde annehmen, dass er dadurch auf eine GroupValueRead Nachricht antwortert. Tut er aber nicht. Mir ist nicht klar wofür dieses Flag gut ist. In der ETS setze ich das L Flag um dem Aktor mitzuteilen auf Statusanfrage zu antworten. Dort sind alle Informationen verfügbar.
Das gleiche gilt für das neu hinzugekommene "Update". Ich bemerke keinen Unterschied beim Ändern des Werts.

Dem Entwickler ist es überlassen seinen Code zu verschleiern. Dann muss er sicherstellen dass die Funktion und Nutzung so weit dokumentiert ist, dass man die Software ohne experimentieren einsetzen kann. Ich sehe viele offene Fragen in den Foren und resignierte Anwender. Ursprünglich bin ich davon ausgegangen, der KNX Adapter verhält sich auf dem Bus wie ein kommerziell verfügbares Gerät. Durch fehlgeschlagene Tests werden mir Einschränkungen nach und nach bewusst. Die Notwendigkeit deiner Workarounds musstest du auch erstmal herausfinden.

[Garfonso]

Auf GroupValueRead reagiert der Adapter nicht, oder zumindest habe ich auch noch nicht verstanden wie. Umgekehrt: im ioBroker aktualisieren sich immer alle zu den GAs gehörenden Objekte, wenn etwas auf dem Bus passiert. Das finde ich persönlich auch ganz gut so (da ich den ioBroker als zentrale Datensammelstelle sehe).

Das mit dem "Code verschleiern" gefällt mir auch nicht, dafür gibt es aber wohl irgendwelche lizenztechnischen Gründe. Das war leider vor meiner Zeit und irgendwie habe ich da auch in der Historie hier wenig dazu gefunden. Das finde ich auch sehr schade und vielleicht wäre eine Diskussion darüber gut, ob es nicht doch teile vom Adapter gibt, die doch OpenSource sein könnten und nur der Teil, der tatsächlich das Problem darstellt nicht öffentlich ist. Das würde mir sehr gefallen.

Welche Einschränkungen siehst du denn? Ich muss sagen, dass bei mir die Workarounds eher auf ioBroker Seite sind und im KNX System das alles recht easy ist (wobei ich mich mit KNX auch nicht sooo gut auskenne und daher da sicher nicht die reine Lehre durchführe, sondern fummel bis es geht ;-)).

Zu den Read/Write flags der Objekte im ioBroker noch:

Read=true, WRITE=true =>you are able to trigger a groupValue READ
Read=false,WRITE =true=> write the given value on KNX-bus
Read=true, WRITE=false=> receive a value-change, but Not able to trigger a read

(von hier: https://github.com/ioBroker/ioBroker.knx/issues/67#issuecomment-524615736 )
Also read + write = true -> wenn du auf das StatusGA schreibst, sendet der Adapter ein GroupValueRead auf dem Bus. Das ist ein stranger Hack, finde ich. Aber wie du in der Diskussion im issue siehst, ist das auch etwas der unterschiedlichen Philosophie von KNX und ioBroker geschuldet.
Und ja, volle Zustimmung: die Dokumentation des KNX Adapter ist grausig und es ist total anstrengend sich die Informationen zusammen zu klauben und erfragen und auszuprobieren... das Readme ist allerdings open source. (dokus, die ich schreibe, gefallen mir meist nicht, daher habe ich mich da bisher nicht an einer Verbesserung versucht. Aber ich bin mir relativ sicher, dass chefkoch da nichts gegen Vorschläge haben wird)

[killroy2]

Der Anwendungsfall für GroupValueRead ist imo relativ begrenzt. Wenn ich einen meiner Teilnehmer testweise neu Starte teilt er seine Ausgänge mit GroupValueWrite mit und holt sich die Eingänge mit Response auf Read. Für weitere Updates hört er permanent am Bus. Im normalen Betrieb sind mir Reads bisher nicht aufgefallen.
Zum Debuggen hilft es mir manchmal wenn ich später mit dem Busmonitor aufschalte oder wenn ich aktualisierte zyklische Werte anschauen will.
Für IOBroker heisst das: alle Eingansgrössen (in ETS wäre das jedes KO ohne S Flag?) beim Start abholen. Für den Anwender ist das transparent.
Der Fall, dass ein KO ein L Flag ohne Ü setzt, d.h. es will aktiv abgefragt werden, würde ich ignorieren. Wüsste auch nicht wie andere Hersteller damit umgehen die den Wert als Input haben, die Info liegt dem KNX Gerät ja nicht vor.
Eine Response muss IOBroker generieren wenn in dem KO ein L Flag gesetzt ist. Solches Verhalten habe ich in Tests nicht herausklingeln können.
So ein Modell über Dialoge beim Import aufzubauen ist ungünstig, da es Kenntnisse über die KNX Welt vom Nutzer erfragt. Besser ist die Daten in der ETS zu halten, dort kann ich auch viel besser Gültigkeit validieren.

Also read + write = true -> wenn du auf das StatusGA schreibst, sendet der Adapter ein GroupValueRead auf dem Bus.

Wenn ich das probiere geht erst mal ein GroupValueWrite voraus. Bedeutet sowas wie prüfen ob schreiben geklappt hat. Mir ist nicht klar was das soll.

[Garfonso]

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

Wenn ich das probiere geht erst mal ein GroupValueWrite voraus. Bedeutet sowas wie prüfen ob schreiben geklappt hat. Mir ist nicht klar was das soll.

Hm... bei mir hat er, wenn beides true war, tatsächlich kein GroupValueWrite gemacht. Woran das dann genau liegt, kann ich auch nicht sagen. Den Anwendungsfall für aktives Triggern von GroupValueRead, sehe ich aber auch nicht wirklich.

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

Für IOBroker heisst das: alle Eingansgrössen (in ETS wäre das jedes KO ohne S Flag?) beim Start abholen.

Dazu sagt chefkoch immer, dass ein L-Flag dazu führt, dass der Adapter beim Start ein GroupValueRead schickt.

[hotze78]

Probleme mit KNX multicast. 224.0.23.12
Ist es geplant, dass der Adapter in Zukunft direkt Multicast tauglich ist? Bei openHab ist dies beispielsweise kein Problem.
Da ich bei meinem KNX-Router nur eine gleichzeitige Gateway Verbindung habe, möchte ich diese für die ETS lassen.
Mit der Installation von eibd knxd und iobrocker bin ich auch noch auf keinen grünen Zweig gekommen. Genaue Anleitung dazu?

Der Import von knxproj hat bisher auch nicht funktioniert. nicht mal mit einem leeren Projekt mit 5 zugewiesenen Adressen.
NACHTRAG: Habe geschützt 6x das gleiche getan, neuer Adapter, selbe Datei, und plötzlich funktioniert es. das selbe mit meiner grossen datei, nicht beim ersten versuch öffnet popupfenster.

Aus Nodered auf dem gleichen System geht es mit allen Dateien und mit multicast.

Betriebssystem linux
Raspberry 4
Node.js v10.17.0
NPM 6.11.3
knx 1.0.36
ETS 5.7.2

[killroy2]

Mit den aktuellen Versionen habe ich Probleme mit Sendeverzug auf Bus. Oft gehen auch Nachrichten verloren.

Im Beispiel wird auf ein Ereignis in NodeRed gleichzeitig auf mehrere (5) KNX Adressen geschrieben. Der Vorgang zieht sich über 3 Sekunden.

Im Log sehe ich die Queue öfters ansteigen:

knx.0 2019-11-16 21:32:18.805 info ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 54 1c 00 ChID : 84 SeqCntIN : 28 SeqCntOUT : 11 queue length : 3

[mgeramb]

Hallo,
vorweg, ich bin neu bei ioBroker (war bisher OpenHAB User und Entwickler).
Nun möchte ich aber ioBroker verwenden und versuche den knx-Adapter zum Laufen zu bringen.
Der Verbindungsaufbau zu KNX klappt wunderbar und im Log sehe ich das auch die Statusmeldungen bei ioBroker ankommen. Vielen Dank an der Stelle für den Adapter!

Leider klappt aber der Import der knxproj Datei nicht.

In der Oberfläche bleibt der Balken einfach stehen, der ioBroker Log zeigt keinerlei Info an, jedoch kommt folgender Fehler in der Browser Console:

Uncaught TypeError: Cannot read property 'getData' of undefined
at getData (index_m.html?0:172)
at Object.getEntryFile (index_m.html?0:179)
at readFiles (index_m.html?0:478)
at index_m.html?0:469
at VM132 zip.js:669
at FileReader.reader.onload (VM132 zip.js:180)

Ich kann auch gerne bei Bedarf meine knxproj Datei zur Verfügung stellen.

ioBroker Adapter: 1.0.36
nodejs: v10.17.0
js-controller: 2.1.0

Liebe Grüße, Michael

[tombox]

@mgeramb nutze die 1.0.31 du kannst bei Adaptern bei dem plus eine andere Version auswähle

[mgeramb]

@tombox
Leider der gleiche Fehler auch mit Version 1.0.31

[killroy2]

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

Mit den aktuellen Versionen habe ich Probleme mit Sendeverzug auf Bus. Oft gehen auch Nachrichten verloren.

Im Beispiel wird auf ein Ereignis in NodeRed gleichzeitig auf mehrere (5) KNX Adressen geschrieben. Der Vorgang zieht sich über 3 Sekunden.

Im Log sehe ich die Queue öfters ansteigen:

knx.0 2019-11-16 21:32:18.805 info ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 54 1c 00 ChID : 84 SeqCntIN : 28 SeqCntOUT : 11 queue length : 3

Ich bin jetzt auf die Version 1.0.20 ungestiegen. Damit tritt diese Art des Fehlers nicht oder in verminderter Form auf.
Leider hat die Version den Fehler, dass ein einzelner KNX Empfang mehrfach triggert. Der Feheler wurde von 1.0.31 auf 1.0.32 behoben.

[sweeper]

Hallo liebe Community!

Ich nutze aktuell den Gira X1 bzw. Openhab zur Visualisierung. Nachdem ich mir nun IoBroker etwas näher angesehen habe, möchte ich nun Schritt für Schritt umstellen. Ich habe auch in den letzten Tagen bereits der VISU begonnen und doch einige Stunden damit verbracht. Nun habe ich aber leider entdeckt, dass die Rückmeldungen nicht wie gewohnt funktionieren. (verglichen zu Openhab etc.)

Ich versuche bereits seit geraumer Zeit den KNX Adapter inkl. Rückmeldungen zum Laufen zu bekommen, jedoch leider nur mit Teilerfolg. Ich habe die Doku von GitHub gelesen und das Forum durchsucht, jedoch ohne einen wesentlichen Hinweis wie die Gruppenadressen ggf. aufgebaut sein müssen, damit eine automatische Verlinkung durchgeführt werden kann.

In einem Beitrag habe ich etwas von 90% Matching gelesen. Bei meinem nachfolgenden Problem inkl. Bsp. müsste die 90% Regel greifen - tut sie aber nicht.

Problem:
Die Rückmeldungsobjekte werde NICHT automatisch mit den Schaltobjekten verbunden. Wenn ich es manuell durchführe dann geht es, aber das wäre eindeutig zu mühsam. Gleiches gilt auch für Raffstores, Dimmer sowie Binäreingänge.

Bleiben wird zunächst mal beim Licht.

Verwendeter KNX Adapter: 1.0.36

Bsp:
Schaltobjekt in ETS: EG Büro Bel. Deckenlicht (L1) s
Rückmeldung in ETS: EG Büro Bel. Deckenlicht (L1) RMs

s ... Schalten
RMS ... Rückmeldung Schalten

Schaltobjekt in IoBroker:

{
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1574026569629,
  "common": {
    "name": "EG Büro Bel. Deckenlicht (L1) s",
    "type": "boolean",
    "role": "switch",
    "read": false,
    "write": true,
    "min": false,
    "max": true
  },
  "native": {
    "dpt": "DPT1.001",
    "address": "1/1/62",
    "addressRefId": "P-03C7-0_GA-63",
    "statusGARefId": "",
    "actGARefId": ""
  },
  "acl": {
    "object": 1638,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1638
  },
  "_id": "knx.0.Beleuchtung_&_schaltbare_Steckdosen.Schalten_(Ein_Aus)_-_Neuanlage_immer_hier!_-.EG_Büro_Bel__Deckenlicht_(L1)_s",
  "type": "state"
}

Rückmeldung in IoBroker:

{
  "_id": "knx.0.Beleuchtung_&_schaltbare_Steckdosen.Rückmeldung_schalten_(Ein_Aus_1Bit)_-_Kopieren!_-.EG_Büro_Bel__Deckenlicht_(L1)_RMs",
  "type": "state",
  "common": {
    "name": "EG Büro Bel. Deckenlicht (L1) RMs",
    "type": "boolean",
    "read": true,
    "write": false,
    "role": "value",
    "min": false,
    "max": true
  },
  "native": {
    "dpt": "DPT1.001",
    "address": "1/4/62",
    "addressRefId": "P-03C7-0_GA-343",
    "statusGARefId": "",
    "actGARefId": ""
  },
  "from": "system.adapter.knx.0",
  "user": "system.user.admin",
  "ts": 1574026571040,
  "acl": {
    "object": 1638,
    "state": 1638
  }
}

statusGARefId und actGARefId werden nicht automatisch befüllt.

Kann mir bezgl. diesem Thema möglicherweise jemand auf die Sprünge helfen?

Bei Bedarf kann ich auch gerne mein KNX Projekt übermitteln.

VG + Danke

[tombox]

@sweeper Rückmeldung muss EG Büro Bel. Deckenlicht (L1) s status heißen

[Garfonso]

@sweeper
Wie tombox schon sag, automatische Verlinkung funktioniert eigentlich nur zuverlässig, wenn der Name von StatusGA = ActGA + " Status".

Irgendwie werden wohl mittlerweile auch die ganzen Pfade der GAs genutzt, das hat bei mir die Rollanden-GAs etwas zerhauen, da weiß ich nicht genau warum oder was da geändert wurde.