UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Tobi68]

@garfonso
Jupp..:crying_cat_face:

Smarthome ist bei mir eher ne Winterangelegenheit..
Werds mal beobachten, evtl. passt ja doch was in der ETS nicht. Ich habe in dem xxl Log auch gesehen das Statusmeldungen teilweise ins leere laufen.
Wenn ich die VIS aufmache, passt der Status von den Buttons auch nicht immer zum Schaltzustand..

Zur Not mache ich echt den Neustart des Adapters Nachts um 2.00 und klemm mich erst im Herbst/Winter wieder dahinter.
Mir ging es in den ersten Zügen im IOB eh erst mal um die Funktion unds verstehen..

[Markus84]

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.

[killroy2]

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

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

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

[Hant0r]

Vielleicht eine doofe Frage, aber wieso habt ihr GA(s) wozu es auf der ETS Seite keinen Abnehmer gibt?

[Tobi68]

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

[Garfonso]

@tobi68
also die GAs sind noch komplett leer im ETS?

[Tobi68]

@garfonso

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

[Markus84]

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

[Garfonso]

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

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

@markus84
Ok, das kann so nicht sein, das mache ich ständig und sehe keine Probleme. Also muss es nochwas zusätzlich sein...?

[Markus84]

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

[lessthanmore]

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]

@markus84
Ja, das wird es dann wohl sein... hm...

[Garfonso]

@lessthanmore
Guck mal bei "Küche", ob da StatusGA und ActGA falsch verknüpft sind.

[lessthanmore]

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

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

[killroy2]

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  - info: 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  - info: 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:1487

Mein 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