Test Adapter KNX v1.0.x

killroy2

zu diesem Thema habe ich noch eine Frage

@chefkoch009 Starter 10 Jun 2019, 13:15

Wenn im ETS Projekt:
"KÜ" gesetzt ist: Dann darf dieses KO mit dem Bus reden (i.d.R. bei Änderungen (DimmwertStatus, o.ä)), es darf aber weder beschrieben noch gelesen werden.

"KSÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf etwas darauf schreiben (z.B. 0(true) oder 1(false) für DPT 1.xxx oder einen Dimmwert oder ....) UND das KO darf eine Änderung auf diesem KO senden was aber i.d.R keinen Sinn macht, denn dafür gibt es ja das Statusobjekt. Historisch gesehen gab es damals Aktoren bei denen war Schalt- und Statusobjekt das gleiche.

"KLÜ" gesetzt ist: Dann darf das KO mit dem Bus reden UND ich darf es abfragen (beim Adapter wird irgend ein Wert an diese GA gesendet und das KO antwortet dann....das ist die aktive Abfrage) UND das KO darf selbständig eigene Änderungen dem Bus mitteilen.

"KLSÜ" gesetzt ist: Rein logisch gesehen, wenn der Aktor getrennte Schalt- und Statusadressen hat, sinnfrei und sorgt aktiv für Verwirrung. Leider werden diese Flags pauschal in einigen Herstellerapplikationen gesetzt. Warum? Keine Ahnung.

Also: Bei SchaltKO's "KS" Flags setzen und bei StatusKO's "KLÜ".

ALLE GA's die ein "L" Flag tragen werden beim Adapterstart abgefragt.

Mit "ich" meinst du wahrscheinlich den KNX Adapter bzw. Importer.
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?

nightstore

Hallo zusammen!

lange benutze ich schon den Knx adapter und war sehr zufrieden,
Danke @chefkoch. Nun nach dem update des Adapters auf die Aktuellste Version 1.0.36 sind einige Probleme bei mir aufgetreten.
Heizungen lassen sich nicht mehr in iobroker einstellen.
Auch die Zeit kann nicht mehr an meine Raumcontroller gesendet werden.
von meinen Skripten funktionieren nur noch wenige.
Mir ist unklar, ob ich auf true und false oder 0 und 1 setzen soll, das Häckchen, war ja standart auf tue & false gesetzt.
Wenn ich wieder zurück aus 1.1.20 gehe, funktioniert die Heiznung wieder.
Verwendet wird die aktuelle ETS Version 5.72
Das Problem ist, wenn ich die Objekte des KNX Adapters lösche und neu einlese, da hab ich soviel geändert, Räume, smartNamen, units, min-max werte, datenpunkte, da sitze ich wieder sehr lange dran um das alles wieder so hinzubekommen.
schönes WE!

killroy2

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

1.0.36

1.0.36 ist bei mir auch unbrauchtbar. Senden und Empfangen über Bus ist träge, oft gehen Nachrichten verloren.
Ich bin zurück auf 1.0.35, damit sind diese Probleme wieder weg.

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.

Garfonso created this issue in ioBroker/ioBroker.knx

closed Import problem range of undefined #77

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

@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 · 1.0.36

@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)

Garfonso created this issue in ioBroker/ioBroker.knx

closed Adapter only sending "GroupValueRead" despite S flag #67

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 · ioBroker Adapter: 1.0.36 nodejs: v10.17.0 js-controller: 2.1.0

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

NEWS