NEWS
Test Adapter KNX v1.0.x
-
Ich habe folgendes Problem: Beim Versuch in manche GAs zu schreiben stürzt der Adapter einfach ab und reagiert für mehrere Minuten nicht. Das Problem tritt nur bei einzelnen GAs auf. Der Adapter wird die ganze Zeit als Grün angezeigt und fängt sich nach ein paar Minuten von selbst wieder.
Ich glaub das Problem liegt in Zeile 8 und 9, dass hier etwas nicht richtig empfangen wird.
@Garfonso Hast du zufällig eine Idee woran das liegen könnte?
knx.0 2021-06-10 10:58:52.902 silly (14509) States user redis pmessage knx.0.*/knx.0.info.connection:{"val":true,"ack":true,"ts":1623315532685,"q":0,"from":"system.adapter.knx.0","user":"system.user.admin","lc":1623313230894} knx.0 2021-06-10 10:58:52.176 info (14509) Change state from STATE_CONNECTION_STATE_RESPONSE(6) to STATE_READY(7) knx.0 2021-06-10 10:58:52.176 info (14509) Change state from STATE_CONNECTION_STATE_REQUEST(5) to STATE_CONNECTION_STATE_RESPONSE(6) knx.0 2021-06-10 10:58:52.176 info (14509) Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 10 00 192.168.100.200:3671 ChID : 16 SeqCntIN : 45 SeqCntOUT : 5 msgCode knx.0 2021-06-10 10:58:52.175 info (14509) Change state from STATE_READY(7) to STATE_CONNECTION_STATE_REQUEST(5) knx.0 2021-06-10 10:58:52.174 info (14509) Send : conCheck Connection State Request : 06 10 02 07 00 10 10 00 08 01 00 00 00 00 d2 53 sent to 192.168.100.200:3671 knx.0 2021-06-10 10:58:52.173 info (14509) checkConnectionState 192.168.100.200 State : true knx.0 2021-06-10 10:58:49.577 info (14509) ( 3.6b ) Received L_DATA.con 06 10 04 20 00 15 04 10 2d 00 2e 00 9d e0 11 04 0a 3b 01 00 80 was NOT processed by receiver !! knx.0 2021-06-10 10:58:48.600 info (14509) ( 3.6b ) Received L_DATA.con 06 10 04 20 00 15 04 10 2d 00 2e 00 9d e0 11 04 0a 3b 01 00 80 was NOT processed by receiver !! knx.0 2021-06-10 10:58:48.534 info (14509) ==> easy-knx.js: signal runtime : 0s 5.43514ms knx.0 2021-06-10 10:58:48.533 info (14509) Change state from STATE_TUNNELLING_SENT_DATA_ACK_RECV(11) to STATE_READY(7) knx.0 2021-06-10 10:58:48.533 info (14509) ==> successful acknowledged previous package... processing next of 0 knx.0 2021-06-10 10:58:48.533 info (14509) STATE_TUNNELLING_WAIT_SENT_ACK: received ACK for previous self sent package knx.0 2021-06-10 10:58:48.532 info (14509) Change state from STATE_TUNNELLING_WAIT_SENT_ACK(9) to STATE_TUNNELLING_SENT_DATA_ACK_RECV(11) knx.0 2021-06-10 10:58:48.532 info (14509) ( 2 ) Received TUNNEL_ACK : 06 10 04 21 00 0a 04 10 04 00 from 192.168.100.200:3671 SeqCntIN : 44 SeqCntOUT : 5 GA : 0/0/0 knx.0 2021-06-10 10:58:48.531 info (14509) Change state from STATE_TUNNELLING_SENDING_DATA(8) to STATE_TUNNELLING_WAIT_SENT_ACK(9) knx.0 2021-06-10 10:58:48.530 info (14509) easy-knx: task.data : 06 10 04 20 00 15 04 10 04 00 11 00 bc e0 11 04 0a 3b 01 00 80 byteLen : 21 knx.0 2021-06-10 10:58:48.530 info (14509) BINARY CHANGE change from false to 0 knx.0 2021-06-10 10:58:48.529 info (14509) ( 1 ) Sending : GroupValueWrite : 06 10 04 20 00 15 04 10 04 00 11 00 bc e0 11 04 0a 3b 01 00 80 sent to 192.168.100.200:3671 ChID: 16 SeqCntIN : 44 SeqCntOUT : 4 GA : 1/2/59 conCheck.co knx.0 2021-06-10 10:58:48.528 info (14509) Change state from STATE_READY(7) to STATE_TUNNELLING_SENDING_DATA(8) knx.0 2021-06-10 10:58:48.527 info (14509) add to Buffer cnt: 181 : 06 10 04 20 00 15 04 10 04 00 11 00 bc e0 11 04 0a 3b 01 00 80 queue.length : 0 GA : 1/2/59 knx.0 2021-06-10 10:58:48.526 info (14509) easy-knx.js groupValueWrite value: 0 dpt : DPT1.001{"type":"Buffer","data":[6,16,4,32,0,21,4,16,4,0,17,0,188,224,17,4,10,59,1,0,128]} knx.0 2021-06-10 10:58:48.525 info (14509) main.js : tGA.write on Statechange : 1/2/59 P-0C17-0_GA-732 typeof val: boolean false DPT1.001 knx.0 2021-06-10 10:58:48.524 silly (14509) States user redis pmessage knx.0.*/knx.0.Licht.Taster.EG-Kueche-Arbeitsplatte-Taster:{"val":false,"ack":false,"ts":1623315528518,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin knx.0 2021-06-10 10:58:42.201 silly (14509) States user redis pmessage knx.0.*/knx.0.Umwelt.Helligkeit.EG-Buero-Helligkeit:{"val":248.32,"ack":true,"ts":1623315522194,"q":0,"from":"system.adapter.knx.0","user":"system.user.admin","lc":1 knx.0 2021-06-10 10:58:42.172 info (14509) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-06-10 10:58:42.172 info (14509) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-06-10 10:58:42.172 info (14509) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 2c 00 ChID : 16 SeqCntIN : 44 SeqCntOUT : 4 queue length : 0 knx.0 2021-06-10 10:58:42.171 info (14509) =====> STATE_TUNNELING_ACK knx.0 2021-06-10 10:58:42.170 info (14509) Change state from STATE_TUNNELLING_REQUEST(13) to STATE_TUNNELLING_ACK(14) knx.0 2021-06-10 10:58:42.170 info (14509) Change state from STATE_READY(7) to STATE_TUNNELLING_REQUEST(13) knx.0 2021-06-10 10:58:42.169 info (14509) WRITE : mappedName : EG-Buero-Helligkeit dest : 10/4/6 val: 248.32 (DPT9.004) EG-Buero-Helligkeit knx.0 2021-06-10 10:58:42.168 info (14509) ( 3.2 ) Received TUNNEL_REQUEST (WRITE - send ACK ) : 06 10 04 20 00 17 04 10 2c 00 29 00 bc e0 11 66 54 06 03 00 80 26 10 ChID: 16 knx.0 2021-06-10 10:58:40.846 silly (14509) States user redis pmessage knx.0.*/knx.0.Umwelt.Helligkeit.EG-Buero-Helligkeit:{"val":279.2,"ack":true,"ts":1623315520837,"q":0,"from":"system.adapter.knx.0","user":"system.user.admin","lc":16 knx.0 2021-06-10 10:58:40.814 info (14509) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7)Edit: Ich konnte den Fehler noch weiter eingrenzen. Konkret kann der Adapter während dieser Zeit weiter senden. Er empfängt in dieser Zeit nur nichts mehr. Im Gruppenmonitor sieht man, dass alles vom Adapter auf den Bus gesendet wird, was auf dem Bus passiert, kommt aber nicht mehr an.
@markus84 du scheinst das gleiche Symptom zu haben wie ich (siehe mein Beitrag weiter oben).
Wenn es keinen Abnehmer für ein Signal gibt, steigt das Interface aus. Mein Interface ist von MDT, mit einem Interface eines anderen Herstellers tritt das Problem nicht auf. -
@markus84 du scheinst das gleiche Symptom zu haben wie ich (siehe mein Beitrag weiter oben).
Wenn es keinen Abnehmer für ein Signal gibt, steigt das Interface aus. Mein Interface ist von MDT, mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.@killroy2 said in Test Adapter KNX v1.0.x:
Wenn es keinen Abnehmer für ein Signal gibt, steigt das Interface aus. Mein Interface ist von MDT, mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.
Danke, genau daran liegt es. Habe auch ein MDT (SCN-IP000.03).
@Garfonso: Kannst du da etwas dran machen? Es muss ja irgendeine Art von autorecovery geben, da es dann plötzlich wieder funktioniert...
-
@markus84 du scheinst das gleiche Symptom zu haben wie ich (siehe mein Beitrag weiter oben).
Wenn es keinen Abnehmer für ein Signal gibt, steigt das Interface aus. Mein Interface ist von MDT, mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.@killroy2 said in Test Adapter KNX v1.0.x:
mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.
Kannst du mir ein anderes empfehlen?
-
@killroy2 said in Test Adapter KNX v1.0.x:
mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.
Kannst du mir ein anderes empfehlen?
-
Vielleicht eine doofe Frage, aber wieso habt ihr GA(s) wozu es auf der ETS Seite keinen Abnehmer gibt?
@hant0r sagte in Test Adapter KNX v1.0.x:
Vielleicht eine doofe Frage, aber wieso habt ihr GA(s) wozu es auf der ETS Seite keinen Abnehmer gibt?
Habe ich auch, sind halt noch nicht alle Rückmeldeadressen eingerichtet..
Gibt ja nicht nur Smarthome im Leben..
Kann das auch bei mir mit den Problemen mit dem Adapter was zu tun haben?
Meine Knx Lampen schalten nach start und schalten per vis manchmal erst nach ein paar Minuten.
Wollte mich aber erst im Winter wieder dranmachen.. -
@hant0r sagte in Test Adapter KNX v1.0.x:
Vielleicht eine doofe Frage, aber wieso habt ihr GA(s) wozu es auf der ETS Seite keinen Abnehmer gibt?
Habe ich auch, sind halt noch nicht alle Rückmeldeadressen eingerichtet..
Gibt ja nicht nur Smarthome im Leben..
Kann das auch bei mir mit den Problemen mit dem Adapter was zu tun haben?
Meine Knx Lampen schalten nach start und schalten per vis manchmal erst nach ein paar Minuten.
Wollte mich aber erst im Winter wieder dranmachen.. -
Ja, ein paar schon.
Ich hatte im Winter mit mehr Rückmeldungen/Status angefangen.
Ein paar sind mit Sicherheit noch nicht eingerichtet.Gestern hatte ich aber auch Massenhaft Fehlermeldungen vom admin.0:
„Unsubscribe from all states, except systems, because over 3 seconds the number of events is over 200“Und wieder subscribe..
Im Wechsel halt..Hatte nachgeschaut da die Rollläden nicht zur Beschattung gefahren sind..
Habe den Raspi mal kp. neu gestartet.
Seit dem scheint wieder alles IO. werde ich auch mal ne Zeit beobachten.Gruss
-
@garfonso said in Test Adapter KNX v1.0.x:
@tobi68
also die GAs sind noch komplett leer im ETS?bei mir sind alle GA´s in der ETS verknüpft, nur (in dem Fall der Bewegungsmelder) ist nicht angeschlossen.
@markus84
und wenn du auf die komplett leere GA was schickst, reagiert der Adapter nicht mehr?Wenn man da suchen soll, ist es hilfreich möglichst eine komplette Schritt für Schirtt Anleitung zu haben, wie bei euch das Problem immer auftritt. (Das ist natürlich für sporadische Probleme schwierig bis unmöglich).
-
@markus84
und wenn du auf die komplett leere GA was schickst, reagiert der Adapter nicht mehr?Wenn man da suchen soll, ist es hilfreich möglichst eine komplette Schritt für Schirtt Anleitung zu haben, wie bei euch das Problem immer auftritt. (Das ist natürlich für sporadische Probleme schwierig bis unmöglich).
@garfonso said in Test Adapter KNX v1.0.x:
und wenn du auf die komplett leere GA was schickst, reagiert der Adapter nicht mehr?
Das habe ich in der Tat noch nicht ausprobiert. Der Fehler ist ganze einfach nachzustellen und tritt dauerhaft (also nicht nur sporadisch auf): Eine GA ist in der ETS nur mit einem Gerät verknüpft. Sobald man über den ioBroker in die GA etwas sendet, kommen für mehrere Minuten keinerlei Informationen mehr vom BUS an und man kann auch nichts mehr senden.
-
@garfonso said in Test Adapter KNX v1.0.x:
und wenn du auf die komplett leere GA was schickst, reagiert der Adapter nicht mehr?
Das habe ich in der Tat noch nicht ausprobiert. Der Fehler ist ganze einfach nachzustellen und tritt dauerhaft (also nicht nur sporadisch auf): Eine GA ist in der ETS nur mit einem Gerät verknüpft. Sobald man über den ioBroker in die GA etwas sendet, kommen für mehrere Minuten keinerlei Informationen mehr vom BUS an und man kann auch nichts mehr senden.
-
@killroy2 said in Test Adapter KNX v1.0.x:
Wenn es keinen Abnehmer für ein Signal gibt, steigt das Interface aus. Mein Interface ist von MDT, mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.
Danke, genau daran liegt es. Habe auch ein MDT (SCN-IP000.03).
@Garfonso: Kannst du da etwas dran machen? Es muss ja irgendeine Art von autorecovery geben, da es dann plötzlich wieder funktioniert...
-
Hallo zusammen,
ich habe zur Zeit Probleme mit dimmbaren Spots bzw. mit der Anzeige im Adapter.
Beim Helligkeitswert (%) wird bspw. beim Esszimmer korrekt die Prozentzahl zurückgegeben bzw. angezeigt. Bei der Küchen zum Beispiel bekomme ich lediglich den Wert "false %" bzw. "true %".
Weiß jemand zufällig woran das liegen kann?
In der ETS ist beides identisch konfiguriert.Lieben Dank vorab
-
@Garfonso Killroy2 hatte oben darauf hingewiesen, dass es wohl nur mit einem MDT Interface passiert. Hast du vielleicht kein MDT Interface? Ist das vielleicht der 2. Faktor der hinzutreten muss?
-
Hallo zusammen,
ich habe zur Zeit Probleme mit dimmbaren Spots bzw. mit der Anzeige im Adapter.
Beim Helligkeitswert (%) wird bspw. beim Esszimmer korrekt die Prozentzahl zurückgegeben bzw. angezeigt. Bei der Küchen zum Beispiel bekomme ich lediglich den Wert "false %" bzw. "true %".
Weiß jemand zufällig woran das liegen kann?
In der ETS ist beides identisch konfiguriert.Lieben Dank vorab
-
@lessthanmore
Guck mal bei "Küche", ob da StatusGA und ActGA falsch verknüpft sind.@garfonso Jap, genauso war es. Er hat die Status GA teilweise falsch gesetzt. Hab es korrigiert und nach einem Neustart vom Adapter geht es nun :)
Jetzt ist nur noch der Punkt offen, warum ich in lovelace keinerlei custom cards anlegen oder verwenden kann. Aber das schreibe ich dir im anderen Thread ;) -
@killroy2 said in Test Adapter KNX v1.0.x:
mit einem Interface eines anderen Herstellers tritt das Problem nicht auf.
Kannst du mir ein anderes empfehlen?
-
@markus84 said in Test Adapter KNX v1.0.x:
Kannst du mir ein anderes empfehlen?
Ich besitze noch ein älteres Weinzierl 731, damit tritt das Problem nicht auf.
Das Problem habe ich nur mit meinem neuen MDT IP Interface SCN-IP000.03Ich habe mein Problem weiter analysiert:
Wenn ein Paket kein Acknowledge bekommt, zB weil es mit keinem Gerät verknüpft ist steigt mein MDT IP Interface aus, schickt einen DISCONNECT_REQUEST und ist für gewisse Zeit tot auf dem Bus so dass wichtige Informationen verloren gehen.192.168.0.103 PC mit ETS, 192.168.0.10 KNX IP Interface, 192.168.0.8 IOBroker
Die ETS verhält sich korrekt, kein Disconnect, Message wird grün (problematisch) angezeigt:
Der CEMI l_data.con frame mit confirmation error vom Interface wird von der ETS Acknowledged
Der IOBroker Adapter quittiert Paket #10:47 nicht, es wird deswegen ein zweites mal geschickt. Und da es erneut nicht quittiert wird geht das Interface in DISCONNECT_REQUEST.
An der Stelle sieht das Log so aus, den Fehler sieht man nicht:
2021-06-26 03:47:12.892 - [32minfo[39m: knx.0 (1581) ( 3.6b ) Received L_DATA.con 06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00 was NOT processed by receiver !! 2021-06-26 03:47:13.892 - [32minfo[39m: knx.0 (1581) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 10 00 08 01 c0 a8 00 0a 0e 57 - ChannelID 16 SeqCntIN : 43 SeqCntOUT : 215 for 192.168.0.10:1487Mein zweites KNX IP Interface hat keine Probleme weil es auch ohne Confirmation ein L_Data.ind schickt welches vom IOBroker quittiert wird.
Frage ist: Was fordert die Spec und kann ein ACK in den Adapter eingebaut werden?
06 10 04 20 00 15 04 01 63 00 29 00 bc e0 11 fe 02 0c 01 00 80 ChID: 1 L_Data.ind -> ok
06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00 L_Data.con -> bad, nack -
Ich habe mein Problem weiter analysiert:
Wenn ein Paket kein Acknowledge bekommt, zB weil es mit keinem Gerät verknüpft ist steigt mein MDT IP Interface aus, schickt einen DISCONNECT_REQUEST und ist für gewisse Zeit tot auf dem Bus so dass wichtige Informationen verloren gehen.192.168.0.103 PC mit ETS, 192.168.0.10 KNX IP Interface, 192.168.0.8 IOBroker
Die ETS verhält sich korrekt, kein Disconnect, Message wird grün (problematisch) angezeigt:
Der CEMI l_data.con frame mit confirmation error vom Interface wird von der ETS Acknowledged
Der IOBroker Adapter quittiert Paket #10:47 nicht, es wird deswegen ein zweites mal geschickt. Und da es erneut nicht quittiert wird geht das Interface in DISCONNECT_REQUEST.
An der Stelle sieht das Log so aus, den Fehler sieht man nicht:
2021-06-26 03:47:12.892 - [32minfo[39m: knx.0 (1581) ( 3.6b ) Received L_DATA.con 06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00 was NOT processed by receiver !! 2021-06-26 03:47:13.892 - [32minfo[39m: knx.0 (1581) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 10 00 08 01 c0 a8 00 0a 0e 57 - ChannelID 16 SeqCntIN : 43 SeqCntOUT : 215 for 192.168.0.10:1487Mein zweites KNX IP Interface hat keine Probleme weil es auch ohne Confirmation ein L_Data.ind schickt welches vom IOBroker quittiert wird.
Frage ist: Was fordert die Spec und kann ein ACK in den Adapter eingebaut werden?
06 10 04 20 00 15 04 01 63 00 29 00 bc e0 11 fe 02 0c 01 00 80 ChID: 1 L_Data.ind -> ok
06 10 04 20 00 16 04 10 2b 00 2e 00 9c e0 11 fe 01 1c 02 00 80 00 L_Data.con -> bad, nack@killroy2
Das ist mal eine gute Analyse -> kannst du die bitte in ein issue packen (zu dem Problem gibt es schon eins, oder?) damit die nicht untergeht? Ich denke damit müsste man das Problem angehen können (hab leider für KNX immer noch kein ganz funktionierendes entwicklungssetup, muss ich mich nochmal dran setzen). -
Ich wollte jetzt nach ner Zeit mal Rückmeldung geben.
Nach dem Neustart des RPIs habe ich keinerlei Probleme mehr, teste jeden Tag ein zwei mal ob die Buttons aus der Vis beim KNX rummzicken, nichts, keine Probleme.
Werde jetzt mal den Täglichen Neustart des Adapters wieder deaktivieren und weiter beobachten.
Evtl. ist aber auch ein Update der Vis aus den letzten Wochen hilfreich gewesen..
Gruss
Tobi
Support us
780
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge