Test Adapter KNX v1.0.x

sourex

Wenn man die Zuordnung so gemacht hat dann nochmal den KNX Adapter neustarten, damit der das mitbekommt und dann geht es auch. Das Problem dabei ist halt, dass man dann die Objekte nicht löschen und neu einfügen lassen sollte.. Insofern war es für mich irgendwann einfacher im ETS einfach die GAs alle umzubenennen. Denn für das KNX System ist der Name ja irrelevant. Die Aufteilung in Gruppen und Mittelgruppen ist auch nicht wichtig, nur halt der identische Name + Status (oder RM geht wohl auch, mittlerweile).

Danke schon mal für die ausführliche Beschreibung. Wie ich schon sagte ist das manuelle ändern nicht gerade mein Ding, da das doch schon ziemlich aufwendig ist und halt überschrieben wird falls ich es mal neu einlese. Versuche ich es also nochmal mit der Änderung der GA. Da es ja anscheinend bei dir erfolgreich war würde ich dich dazu noch mal befragen, da ich es anscheinend nicht richtig verstanden habe. So habe ich es gemacht aktuell:

Was ist der Fehler ? Ist es eigentlich nötig gewesen jede einzelne GA umzubenennen oder hätten die Mittelgruppen gereicht ? Muss ich anschließend wirklich alle Objekte (zuvor den KNX Adapter) entfernen und dann wieder neu einzulesen ??

Vielen Dank

Hansi1234

Guten Morgen liebe Broker Freunde.
Hat von euch auch jemand das Problem, dass die Lamellenstellung ca. erst eine Minute später reagiert? Auf/Ab reagiert sofort, die Stellung nicht.

MFG
Hansi

Garfonso

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

Was ist der Fehler ?

Was geht denn nicht?
Ich kann auf deinem Bild die Namen der Schalt GAs nicht sehen... ich würde aber vermuten, dass der Adapter nicht mag, dass nach dem RM noch etwas kommt und daher die Zuordnung nicht stimmt.

Bei mir sieht es so aus:
KNX Status.JPG

Wie du siehst sind die Namen der GAs zu 100% identisch (meist habe ich sogar mit copy & paste gearbeitet) nur mit einem "Status" angehängt. Da müsste wohl mittlerweile auch "RM" gehen.

Ist es eigentlich nötig gewesen jede einzelne GA umzubenennen oder hätten die Mittelgruppen gereicht ?

Meine Erfahrung ist, dass der Name der Mittelgruppen egal ist und nur der Name der GAs zählt. Also ja, jede GA muss umbenannt werden.

Muss ich anschließend wirklich alle Objekte (zuvor den KNX Adapter) entfernen und dann wieder neu einzulesen ??

Das würde ich dringend empfehlen. Die ID vom Objekt wird aus dem Namen der GA generiert. Alte Objekte werden dabei vom Adapter nicht gelöscht (was ich auch eher suboptimal finde, könnte er eigentlich machen. Naja. Feature Request)... Daher, wenn du alle GAs umbenennst, dann hast du hinterher doppelt so viele Objekte bei KNX und nur 50% davon gehen, der Rest macht nix... das ist keine sinnvolle Situation.
Achja, ich würde dringend die Nutzung der neuen Alias Funktion oder eigener JS Scripte empfehlen für den KNX Adapter... und dann nur die Alias-Objekte in Skripten, Vis oder Räumen/Funktionen/Typen usw. aufräumen für die Geräteerkennung. Alles andere macht irgendwie keinen Spaß...
Mit einem eigenen JS Script könnte man auch die Zuordnung manuell lösen. Das hatte ich selber auch eine Zeit lang gemacht, aber dann doch irgendwann die ~700 GAs umbenannt nach und nach.

Garfonso

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

Was ist eigentlich der Vorteil wenn ich die Status Adresse korrekt zuordne?

Das sich die Objekte dann so verhalten, wie der ioBroker es erwartet... bei KNX ist es ja im Grunde so, dass du auf der einen GA einen Befehl sendest und auf der Status (oder Rückmeldung) GA kommt der Status und der kommt da auch, wenn jemand anders schaltet (also z.B. ein Taster und nicht der ioBroker).

Im ioBroker ist die Idee aber, dass es nur ein Objekt gibt, was mit ack=false beschrieben wird und so einen Befehl auslöst und vom Adapter mit ack=true beschrieben wird und so eine Statusänderung am Gerät darstellt.

Wenn du z.B. den Vis Adapter nutzen möchtest für eine Visualisierung, dann kannst du da für eine Lampe nur ein objekt eintragen. Trägst du da eine unverknüpfte Schalt-GA ein, dann kannst du zwar mit der Vis schalten, schaltest du aber mit einem Taster z.B., dann siehst du die Änderung nicht in der Vis. Wenn es die Verknüpfung gibt, wird durch die Nachricht des Geräts auf der Status GA im ioBroker (und nur da) auch bei der Schalt-GA der aktuelle Wert eingetragen und es reicht dann im ioBroker aus die Objekte für die Schalt-GA überall zu verwenden und man kann damit dann eine Vis oder Skripte oder was auch immer bauen.

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

Sobald das KNX Objekt empfangen wird schreibt er automatisch das Status Objekt mit dem Wert auf den Bus. Warum er das macht ist mir rätselhaft.

Nein, tut er hier definitiv nicht. Hast du da ggf. irgendwelche Skripte laufen? Und über welche GA schreibt er das? Das solltest du als Bug reporten.

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

Den Status wollte ich über eine Logikfunktion berechnen.

Wie willst du den Status über eine Logikfunktion berechnen? grübel
Du kannst natürlich in einem Skript Status GA und Objekt GA auf ein neues Objekt vereinen. Habe ich auch eine Zeit lang gemacht.

tombox

@Hansi1234 hatte mal probleme weil nicht explizit dpt 1.008 ausgewählt war sondern nur 1.*. Bzw teste mal 1.0.31, 1.0.20 ob sich da was bewegt

Hansi1234

@tombox Guten Morgen,
danke für die Hilfe. Meinst du in ETS oder in io?

tombox

@Hansi1234 ets

Hansi1234

@tombox
Da ist 5.001 hinterlegt. Stimmt doch oder?

tombox

@Hansi1234 Ja geht auch.

Hansi1234

@tombox dann liegt es wohl nicht daran

tombox

@Hansi1234 Kannst nur checken ob im ETS die Werte sofort ankommen. Bzw mal ein paar knx adapter versionen durchprobieren. 1.0.31, 1.0.20

killroy2

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

Status über eine Logikfunktion berechnen? grübel
Du kannst natürlich in einem Skript Status GA und Objekt GA auf ein neues Objekt vereinen. Habe ich auch eine Zeit lang gemacht.

Mit Logikfunktion meine ich ein dynamisches Skript.
z.B. um den Lampenstatus an/aus zu visualisieren wenn die Lampe mehrere Kanäle (weiss, gelb) hat.

Hansi1234

@tombox
Ich teste es eben mit dem Monitor.
Den Befehl erhält er sofort, aber die Aktion führt er erst später aus. Keine Ahnung warum.

#	Zeit	Dienst	Flags 	Prio	Quell-Adresse	Quell-Name	Ziel-Adresse	Ziel-Name	Rout	Typ	DPT	Info
1	06.01.2020 00:09:40,032	Start										Aufzeichnung wurde gestartet, Host=*******, Verbindung=MDT KNX IP Router, Modus=LinkLayer
2	06.01.2020 00:09:44,025	vom Bus		Low	1.1.9	-	0/0/234	HWR Absolute Lamellenposition	6	GroupValueWrite	  5.001 Prozent (0..100%)	$40 | 25 %
3	06.01.2020 00:09:45,027	vom Bus		Low	1.1.9	-	0/0/234	HWR Absolute Lamellenposition	6	GroupValueWrite	  5.001 Prozent (0..100%)	$40 | 25 %
4	06.01.2020 00:10:08,841	vom Bus		Low	1.1.2	JAL-0810.02 Jalousieaktor 8-fach, 8TE, 230VAC, 10A	0/0/235	HWR Status aktuelle Position	6	GroupValueWrite	  5.001 Prozent (0..100%)	$FF | 100 %
5	06.01.2020 00:10:08,885	vom Bus		Low	1.1.2	JAL-0810.02 Jalousieaktor 8-fach, 8TE, 230VAC, 10A	0/0/236	HWR Status akt. Lamellenposition	6	GroupValueWrite	  5.001 Prozent (0..100%)	$FF | 100 %
6	06.01.2020 00:10:10,244	vom Bus		Low	1.1.2	JAL-0810.02 Jalousieaktor 8-fach, 8TE, 230VAC, 10A	0/0/235	HWR Status aktuelle Position	6	GroupValueWrite	  5.001 Prozent (0..100%)	$FA | 98 %
7	06.01.2020 00:10:10,289	vom Bus		Low	1.1.2	JAL-0810.02 Jalousieaktor 8-fach, 8TE, 230VAC, 10A	0/0/236	HWR Status akt. Lamellenposition	6	GroupValueWrite	  5.001 Prozent (0..100%)	$3F | 25 %
8	06.01.2020 00:10:12,816	Stop										Aufzeichnung wurde beendet

shadow18

Erst einmal an großes Lob für den KNX Adapter. Ich bin vor kurzem auf iobroker umgestiegen. Die Version 1.0.36 läuft soweit sehr stabil bis auf die Reconnects alle 2-4 Minuten. Ich habe mal die ältere Version 1.0.31 versucht, hier tritt das Problem nicht auf, aber dafür bricht die Verbindung zum knx ab und wird auch nicht wieder aufgebaut. Ich habe bereits alles versucht, das Problem tritt auch auf, wenn keine KNX Datei importiert ist.

Standard Log:

undefined2020-01-07 15:42:20.285 - info: knx.0 (10211) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
2020-01-07 15:42:20.292 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2020-01-07 15:42:20.298 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0).
2020-01-07 15:42:22.286 - info: knx.0 (10211) Using UDP with local IP: 192.168.2.251
2020-01-07 15:42:22.288 - info: knx.0 (10211) Event : UDP - listening
2020-01-07 15:42:22.298 - info: knx.0 (10211) Connected - local UDP Server listening on 192.168.2.251:36590
2020-01-07 15:44:22.486 - info: knx.0 (10211) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
2020-01-07 15:44:22.490 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2020-01-07 15:44:22.494 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0).
2020-01-07 15:44:24.487 - info: knx.0 (10211) Using UDP with local IP: 192.168.2.251
2020-01-07 15:44:24.487 - info: knx.0 (10211) Event : UDP - listening
2020-01-07 15:44:24.488 - info: knx.0 (10211) Connected - local UDP Server listening on 192.168.2.251:37150
2020-01-07 15:46:24.681 - info: knx.0 (10211) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
2020-01-07 15:46:24.683 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2020-01-07 15:46:24.686 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0).
2020-01-07 15:46:26.682 - info: knx.0 (10211) Using UDP with local IP: 192.168.2.251
2020-01-07 15:46:26.683 - info: knx.0 (10211) Event : UDP - listening
2020-01-07 15:46:26.685 - info: knx.0 (10211) Connected - local UDP Server listening on 192.168.2.251:53972
2020-01-07 15:48:26.885 - info: knx.0 (10211) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
2020-01-07 15:48:26.888 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2020-01-07 15:48:26.892 - info: knx.0 (10211) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0).
2020-01-07 15:48:28.886 - info: knx.0 (10211) Using UDP with local IP: 192.168.2.251
2020-01-07 15:48:28.887 - info: knx.0 (10211) Event : UDP - listening
2020-01-07 15:48:28.889 - info: knx.0 (10211) Connected - local UDP Server listening on 192.168.2.251:34124

Erweiterer Log:

2020-01-07 12:55:19.532 - info: knx.0 (2019) =====> STATE_TUNNELING_ACK
2020-01-07 12:55:19.535 - info: knx.0 (2019) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 34 2f 00 ChID : 52 SeqCntIN : 47 SeqCntOUT : 0 queue length : 0
2020-01-07 12:55:19.535 - info: knx.0 (2019) ( 4.b ) return to STATE_READY, processing : false
2020-01-07 12:55:19.536 - info: knx.0 (2019) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7)
2020-01-07 12:55:22.522 - info: knx.0 (2019) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 34 34 08 01 c0 a8 02 df 0e 57 - ChannelID 52 SeqCntIN : 47 SeqCntOUT : 0 for 192.168.2.223:1487
2020-01-07 12:55:22.523 - info: knx.0 (2019) ( END 1 ) Sending DISCONNECT_REQUEST_RESPONSE : 06 10 02 0a 00 08 25 00 ChID : 0 SeqCntIN : 47 SeqCntOUT : 0 msgCode : [object Object]
2020-01-07 12:55:22.523 - info: knx.0 (2019) Change state from STATE_READY(7) to STATE_DISCONNECT_RESPONSE(16)
2020-01-07 12:55:22.524 - info: knx.0 (2019) Change state from STATE_READY(7) to STATE_NOT_CONNECTED(0)
2020-01-07 12:55:22.524 - info: knx.0 (2019) Connection persists.....closing now
2020-01-07 12:55:22.526 - info: knx.0 (2019) ... not able to close connection, because already closed
2020-01-07 12:55:22.526 - info: knx.0 (2019) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0).
2020-01-07 12:55:22.526 - info: knx.0 (2019) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed
2020-01-07 12:55:22.527 - info: knx.0 (2019) ( END ) Sending DISCONNECT_REQUEST : 06 10 02 09 00 10 34 00 08 01 00 00 00 00 b4 6b ChID : 0 SeqCntIN : 47 SeqCntOUT : 0 msgCode : [object Object]
2020-01-07 12:55:22.527 - info: knx.0 (2019) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15)
2020-01-07 12:55:22.528 - info: knx.0 (2019) STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15).
2020-01-07 12:55:22.528 - info: knx.0 (2019) Change state from STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0)
2020-01-07 12:55:22.528 - info: knx.0 (2019) Connection persists.....closing now
2020-01-07 12:55:22.529 - info: knx.0 (2019) ... not able to close connection, because already closed
2020-01-07 12:55:22.530 - info: knx.0 (2019) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0).
2020-01-07 12:55:22.532 - info: knx.0 (2019) Change state from STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16)
2020-01-07 12:55:22.533 - info: knx.0 (2019) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed
2020-01-07 12:55:22.533 - info: knx.0 (2019) Received DISCONNECT_RESPONSE06 10 02 0a 00 08 34 21
2020-01-07 12:55:22.534 - info: knx.0 (2019) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0)
2020-01-07 12:55:22.534 - info: knx.0 (2019) Connection persists.....closing now
2020-01-07 12:55:22.536 - info: knx.0 (2019) ... not able to close connection, because already closed
2020-01-07 12:55:22.536 - info: knx.0 (2019) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0).

Garfonso

@shadow18
Disconnects alle 2-4 Minuten ist wohl kaum "stabil".
Von welcher Version ist das Log?
In jedem Fall sieht es so aus, als ob die Gegenseite dem ioBroker sagt, er soll sich jetzt trennen. Hat deine IP Bridge vielleicht nur eine Verbindung (aus irgendeinem Grund sind die meist begrenzt, meine hat 3 mögliche gleichzeitige Verbindungen, zum Glück) und z.B. ein ETS läuft noch irgendwo und will auch verbinden und die zwei "streiten" sich um die einzige Verbindung?

shadow18

@Garfonso hast du auch wieder Recht
Ich nutze den neusten Adapter 1.0.36.

Ich nutze den Enertex KNX Router, hier habe ich 5 Kanäle, 2 sind noch frei siehe Bild.

Garfonso · @Garfonso hast du auch wieder Recht Ich nutze den neusten Adapter 1.0.36.

@shadow18
ok, dann bin ich überfragt... aber es sieht für mich irgendwie nicht so aus, als ob die disconnects am Adapter liegen... spontan wäre meine Idee mal alles neuzustarten, also PC und KNX Router...

shadow18

@Garfonso

So ich habe dein Tipp mal aufgegriffen. Ich habe noch ein Gira X1, das ja auch Tunnel zur Verfügung stellt. Also IP geändert und siehe da seit 10 min. kein Reconnect. Also muss es an dem Enertex Router liegen.

sinner

Interessant, ich habe den IP-Router von Gira (4 gleichzeitige Verbindungen) und permanent ist eigentlich nur der Homeserver darüber verbunden. Dazu kommt für Programmiervorgänge hin und wieder ETS.
Der Adapter v1.0.35 meldet bei mir auch permanente Disconnects alle paar Minuten, die v1.0.36 meldet diese auch, allerdings funktioniert die Kommunikation mit dem Bus mit dieser Version bei mir nicht, daher kann ich die nicht verwenden.

fuchs1978

Ich nutze das IP Interface von Enertex. Nach der Version 1.0.20 baut der Adapter keine Verbindung mehr auf. Kann ich sinnvolle Debug Daten für den Entwickler aus Iobroker ziehen?

NEWS

Test Adapter KNX v1.0.x

Test Adapter KNX v1.0.x

Support us

78

32.4k

81.3k

1.3m