NEWS
Test Adapter KNX v1.0.x
-
@garfonso
Bei mir ist Pakete pro Sekunde auf 30 eingestellt.
Dass KNX auch bei niederer Last bei mir aussetzt hat denke ich nichts mit Iobroker zu tun, ich sehe dann in der ETS im Gruppenmonitor eine Meldung Verbindung verloren und kurz später Verbindung hergestellt. Ich habe das Ethernet Interface im Verdacht und werde mal austauschen. Bis dahin und auch generell versuche ich mein System robuster zu gestalten.Nach Adapterneustart fragt er bei mir auch jede Menge ab. Genau das möchte ich selber triggern, geht das?
@killroy2 said in Test Adapter KNX v1.0.x:
Nach Adapterneustart fragt er bei mir auch jede Menge ab. Genau das möchte ich selber triggern, geht das?
Am einfachsten über Adapter-Neustart, wenn du merkst, dass das Interface weg war. Nicht? ;-)
Sonst kannst du die StatusGA so einstellen (ich meine read & write auf true -> siehe Readme des Adapters in der Tabelle), dass die bei einem write auf den State ein GroupValueRead an den Bus schicken und damit dann den Wert aktualisieren.Ich habe bei mir ehrlich gesagt die meisten KNX Geräte so eingestellt, dass sie zyklisch ihren Status senden.
-
@garfonso As you seem to be an experienced user of the adapter, could you verify that you really get all DPs updated when receiving GroupValueRespons after the start of the adapter? For me and some other users, some DPTs doesn't work 100%. For example DPT 5.001. I have not been able to get any help regarding this and I can't understand how it can be a problem just with my (and some other few users) installation.
The easiest way to reproduce the Issue:
- Switch a dimmer light off. Notice the dim value object (should be 0%)
- Turn off KNX Adapter instance
- Switch the dimmer light on
- Turn on KNX Adapter instance
- Notice the dim value object (should be anything else than 0%)
If your DP still shows 0% it would make it likely to be a general bug for all installations. If you get the correct %, I need to look into what's wrong with my ioBroker.
This is the Github issue: https://github.com/ioBroker/ioBroker.knx/issues/162#issuecomment-838082533
@videonisse
I followed your steps and it works perfectly fine for me.I can not guarantee that all states are updated, but whenever I checked, the state was updated during startup. If I watch the bus in ETS I also can see the adapter sending out a lot of GroupValueRead messages.
Do you generally see updates from the bus in the states? Are the action and status GAs linked in ioBroker?
-
@videonisse I am not sure if it is in any way related to your problem, but I found out a couple of thinks that make the adapter unresponsive for a couple of minutes:
- Do not sent an empty string to an ASCII GA
- I changed the structure of a GA from Temperatur (Ist) to Temperatur-Ist. The former datapoint in ioBroker worked fine, the new datapoint was not working properly. After deleting all datapoints from knx.0. and reimporting the same ETS project file again the new dataipoints worked. Not sure what it causes it. The RAW values looked almost the same. Only one value was different, I think it was "ts".
- I write several information from ioBroker to GAs. The GAs only exist to show information on a MDT LED Display. When I physically disconnect the MDT LED and update one of these GAs, the adapter does not receive any GA changes for a couple of minutes.
@Garfonso Ich weiß du bist nicht der ursprüngliche Entwickler des Adapters, aber bist du der richtige Ansprechpartner für solche Bugmeldungen? Fehler eins habe ich auf Github gemeldet. Macht es Sinn die beiden anderen Punkte auch zu melden? Wird der Adapter durch den ursprünglichen Entwickler oder dich fortentwickelt?
@markus84 said in Test Adapter KNX v1.0.x:
Macht es Sinn die beiden anderen Punkte auch zu melden? Wird der Adapter durch den ursprünglichen Entwickler oder dich fortentwickelt?
Bitte auf jeden Fall github issues und möglichst mit allen Infos.
Ich habe bisher leider keine Zeit gefunden in den code zu gucken... aber wenn ich das mal schaffe, ist es auf Github am übersichtlichsten die Probleme abzuarbeiten.
-
@markus84 said in Test Adapter KNX v1.0.x:
Macht es Sinn die beiden anderen Punkte auch zu melden? Wird der Adapter durch den ursprünglichen Entwickler oder dich fortentwickelt?
Bitte auf jeden Fall github issues und möglichst mit allen Infos.
Ich habe bisher leider keine Zeit gefunden in den code zu gucken... aber wenn ich das mal schaffe, ist es auf Github am übersichtlichsten die Probleme abzuarbeiten.
-
@videonisse
I followed your steps and it works perfectly fine for me.I can not guarantee that all states are updated, but whenever I checked, the state was updated during startup. If I watch the bus in ETS I also can see the adapter sending out a lot of GroupValueRead messages.
Do you generally see updates from the bus in the states? Are the action and status GAs linked in ioBroker?
@garfonso sagte in Test Adapter KNX v1.0.x:
@videonisse
I followed your steps and it works perfectly fine for me.I can not guarantee that all states are updated, but whenever I checked, the state was updated during startup. If I watch the bus in ETS I also can see the adapter sending out a lot of GroupValueRead messages.
Interesting!
Do you generally see updates from the bus in the states?
Yes. All Boolean values and for example, 0% with DPT 5.001 are updated correctly for me. But a value above 0% is not. (I assume you mean GroupValueRespons. With GroupValueWrite I don't have any problems.)
ALL values are also visible in the log, but the above values are not stored in the states db.
Are the action and status GAs linked in ioBroker?
Yes, they are.
I can't understand what can be wrong with my installation if the values are received correctly by the adapter but not written to the states db. Any ideas on how I can troubleshoot further?
ioBroker v3.3.18, Debian 10 Buster 64-bit (Vmware 6.5 VM), Node.js: v12.22.6, NPM: 6.14.15
Most important Device Adapters: KNX, Trådfri, Homekit/Yahka -
@garfonso sagte in Test Adapter KNX v1.0.x:
@videonisse
I followed your steps and it works perfectly fine for me.I can not guarantee that all states are updated, but whenever I checked, the state was updated during startup. If I watch the bus in ETS I also can see the adapter sending out a lot of GroupValueRead messages.
Interesting!
Do you generally see updates from the bus in the states?
Yes. All Boolean values and for example, 0% with DPT 5.001 are updated correctly for me. But a value above 0% is not. (I assume you mean GroupValueRespons. With GroupValueWrite I don't have any problems.)
ALL values are also visible in the log, but the above values are not stored in the states db.
Are the action and status GAs linked in ioBroker?
Yes, they are.
I can't understand what can be wrong with my installation if the values are received correctly by the adapter but not written to the states db. Any ideas on how I can troubleshoot further?
-
@videonisse
I'll try to have a look at the code in a debug environment some time.Ich habe ein seltsames Problem: Ich versuche alle Rollos über ioBroker zu steuern. Etwa zwei Drittel funktioniert einwandfrei, das verbleibende Drittel funktioniert nicht. Ich kann leider nicht herausfinden woran es liegt. Hier die Gruppenadressen:
Bei den GAs, bei denen kein letzter Wert steht funktioniert es nicht. Es wird anstatt eines GroupValueWrite ein GroupValueRead gesendet.
Hier ein Beispiel eines Datenpunktes bei dem es funktioniert:
{ "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626475652, "common": { "name": "EG-Buero-Rollo-Fahren", "type": "boolean", "role": "", "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/2", "addressRefId": "P-0C17-0_GA-1140", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "MD-2_M-6_MI-1_O-2-23_R-4", "devName": "M-0083_A-0128-43-7CBD", "devInst": "P-0C17-0_DI-24", "objectSize": "" }, "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1636 }, "_id": "knx.0.Beschatten-1.Fahren.EG-Buero-Rollo-Fahren", "type": "state" }Und hier ein Beispiel bei dem es nicht funktioniert:
{ "_id": "knx.0.Beschatten-1.Fahren.OG-Ankleide-Rollo-Fahren", "type": "state", "common": { "name": "OG-Ankleide-Rollo-Fahren", "type": "boolean", "role": "value", "read": true, "write": true, "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/16", "addressRefId": "P-0C17-0_GA-1154", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "O-5_R-11034", "devName": "M-0083_A-008A-27-4A49", "devInst": "P-0C17-0_DI-49", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626479292, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Ich weiß leider nicht, wo ich den Fehler noch suchen soll. Hat jemand eine Idee?
-
Ich habe ein seltsames Problem: Ich versuche alle Rollos über ioBroker zu steuern. Etwa zwei Drittel funktioniert einwandfrei, das verbleibende Drittel funktioniert nicht. Ich kann leider nicht herausfinden woran es liegt. Hier die Gruppenadressen:
Bei den GAs, bei denen kein letzter Wert steht funktioniert es nicht. Es wird anstatt eines GroupValueWrite ein GroupValueRead gesendet.
Hier ein Beispiel eines Datenpunktes bei dem es funktioniert:
{ "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626475652, "common": { "name": "EG-Buero-Rollo-Fahren", "type": "boolean", "role": "", "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/2", "addressRefId": "P-0C17-0_GA-1140", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "MD-2_M-6_MI-1_O-2-23_R-4", "devName": "M-0083_A-0128-43-7CBD", "devInst": "P-0C17-0_DI-24", "objectSize": "" }, "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1636 }, "_id": "knx.0.Beschatten-1.Fahren.EG-Buero-Rollo-Fahren", "type": "state" }Und hier ein Beispiel bei dem es nicht funktioniert:
{ "_id": "knx.0.Beschatten-1.Fahren.OG-Ankleide-Rollo-Fahren", "type": "state", "common": { "name": "OG-Ankleide-Rollo-Fahren", "type": "boolean", "role": "value", "read": true, "write": true, "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/16", "addressRefId": "P-0C17-0_GA-1154", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "O-5_R-11034", "devName": "M-0083_A-008A-27-4A49", "devInst": "P-0C17-0_DI-49", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626479292, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Ich weiß leider nicht, wo ich den Fehler noch suchen soll. Hat jemand eine Idee?
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
-
Hallo,
nach Installation eines neuen KNX IP Interfaces ist die KNX Verbindung mit IOBroker sehr instabil. Ich habe Probleme dass Empfangstelegramme vom Bus nicht im Iobroker Objektbaum aktualisiert werden. Das Problem ist sporadisch, manchmal werden die Werte auch empfangen. Senden scheint okay zu sein.
ETS läuft ohne Verbindungsprobleme.
Mein Interface ist ein MDT SCN-IP000.03 IP Interface mit Secure.
ich verwende die aktuelle Version vom KNX Adapter 1.0.45.Hier mal ein Log von einen Gutfall:
knx.0 2021-05-23 16:19:20.849 info (3320) add to Buffer cnt: 58 : 06 10 04 20 00 16 04 10 06 00 11 00 bc e0 11 07 01 2d 02 00 80 8c queue.length : 0 GA : 0/1/45 knx.0 2021-05-23 16:19:20.848 info (3320) easy-knx.js groupValueWrite value: 55 dpt : DPT5.001{"type":"Buffer","data":[6,16,4,32,0,22,4,16,6,0,17,0,188,224,17,7,1,45,2,0,128,140]} knx.0 2021-05-23 16:19:20.847 info (3320) main.js : tGA.write on Statechange : 0/1/45 P-03DA-0_GA-421 typeof val: number 55 DPT5.001 knx.0 2021-05-23 16:19:20.825 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:19:20.825 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:19:20.825 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 0d 00 ChID : 16 SeqCntIN : 13 SeqCntOUT : 6 queue length : 0 knx.0 2021-05-23 16:19:20.824 info (3320) =====> STATE_TUNNELING_ACK knx.0 2021-05-23 16:19:20.823 info (3320) Change state from STATE_TUNNELLING_REQUEST(13) to STATE_TUNNELLING_ACK(14) knx.0 2021-05-23 16:19:20.823 info (3320) Change state from STATE_READY(7) to STATE_TUNNELLING_REQUEST(13) knx.0 2021-05-23 16:19:20.823 info (3320) WRITE : mappedName : UG Hobby Sollwert dest : 0/4/57 val: 55 (DPT5.001) UG_Hobby_Sollwert knx.0 2021-05-23 16:19:20.822 info (3320) ( 3.2 ) Received TUNNEL_REQUEST (WRITE - send ACK ) : 06 10 04 20 00 16 04 10 0d 00 29 00 bc e0 11 03 04 39 02 00 80 8c ChID: 16 knx.0 2021-05-23 16:19:20.394 info (3320) Change state from STATE_CONNECTION_STATE_RESPONSE(6) to STATE_READY(7) knx.0 2021-05-23 16:19:20.393 info (3320) Change state from STATE_CONNECTION_STATE_REQUEST(5) to STATE_CONNECTION_STATE_RESPONSE(6) knx.0 2021-05-23 16:19:20.393 info (3320) Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 10 00 192.168.0.10:3671 ChID : 16 SeqCntIN : 12 SeqCntOUT : 6 msgCode : [o knx.0 2021-05-23 16:19:20.392 info (3320) Change state from STATE_READY(7) to STATE_CONNECTION_STATE_REQUEST(5) knx.0 2021-05-23 16:19:20.392 info (3320) Send : conCheck Connection State Request : 06 10 02 07 00 10 10 00 08 01 00 00 00 00 d8 2b sent to 192.168.0.10:3671 knx.0 2021-05-23 16:19:20.391 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:19:20.391 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:19:20.391 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 0c 00 ChID : 16 SeqCntIN : 12 SeqCntOUT : 6 queue length : 0Und hier ein Schlechtfall:
knx.0 2021-05-23 16:21:25.034 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:21:25.034 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:21:25.034 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 00 00 ChID : 16 SeqCntIN : 0 SeqCntOUT : 0 queue length : 0 knx.0 2021-05-23 16:21:25.031 info (3320) =====> STATE_TUNNELING_ACK knx.0 2021-05-23 16:21:25.031 info (3320) Change state from STATE_TUNNELLING_REQUEST(13) to STATE_TUNNELLING_ACK(14) knx.0 2021-05-23 16:21:25.030 info (3320) Change state from STATE_READY(7) to STATE_TUNNELLING_REQUEST(13) knx.0 2021-05-23 16:21:25.030 info (3320) WRITE : mappedName : DG Nord Lichtwert dest : 9/0/15 val: 644.48 (DPT9.004) DG_Nord_Lichtwert knx.0 2021-05-23 16:21:25.029 info (3320) ( 3.2 ) Received TUNNEL_REQUEST (WRITE - send ACK ) : 06 10 04 20 00 17 04 10 00 00 29 00 bc e0 11 c9 48 0f 03 00 80 2f de ChID: 16 knx.0 2021-05-23 16:21:24.507 info (3320) Change state from STATE_CONNECT_RESPONSE(4) to STATE_READY(7) knx.0 2021-05-23 16:21:24.507 info (3320) Received CONNECTION_RESPONSE : 06 10 02 06 00 14 10 00 08 01 00 00 00 00 00 00 04 04 11 02 GW-IP: 192.168.0.10:3671 - ChannelID: 16 cnt IN/OUT: 0/0 knx.0 2021-05-23 16:21:24.506 info (3320) Change state from STATE_CONNECT_REQUEST(3) to STATE_CONNECT_RESPONSE(4) knx.0 2021-05-23 16:21:24.505 info (3320) Change state from STATE_PORT_OPENED(2) to STATE_CONNECT_REQUEST(3) knx.0 2021-05-23 16:21:24.505 info (3320) Send : UDP Connection Request : 06 10 02 05 00 1a 08 01 c0 a8 00 08 d9 ac 08 01 00 00 00 00 d9 ac 04 04 02 00 sent to 192.168.0.10:3671 knx.0 2021-05-23 16:21:24.505 info (3320) Connected - local UDP Server listening on 192.168.0.8:55724 knx.0 2021-05-23 16:21:24.505 info (3320) Change state from STATE_OPENING_PORT(1) to STATE_PORT_OPENED(2) knx.0 2021-05-23 16:21:24.505 info (3320) Event : UDP - listening knx.0 2021-05-23 16:21:24.504 info (3320) Change state from STATE_NOT_CONNECTED(0) to STATE_OPENING_PORT(1) knx.0 2021-05-23 16:21:24.504 info (3320) Using UDP with local IP: 192.168.0.8 knx.0 2021-05-23 16:21:22.522 info (3320) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.520 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.516 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.515 info (3320) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.515 info (3320) Received DISCONNECT_RESPONSE06 10 02 0a 00 08 10 21 knx.0 2021-05-23 16:21:22.514 info (3320) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed knx.0 2021-05-23 16:21:22.514 info (3320) Change state from STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) knx.0 2021-05-23 16:21:22.509 info (3320) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.509 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.506 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.505 info (3320) Change state from STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.505 info (3320) STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15). knx.0 2021-05-23 16:21:22.505 info (3320) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15) knx.0 2021-05-23 16:21:22.504 info (3320) ( END ) Sending DISCONNECT_REQUEST : 06 10 02 09 00 10 10 00 08 01 c0 a8 00 08 d8 2b ChID : 0 SeqCntIN : 17 SeqCntOUT : 58 msgC knx.0 2021-05-23 16:21:22.504 info (3320) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed knx.0 2021-05-23 16:21:22.503 info (3320) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.503 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.499 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.499 info (3320) Change state from STATE_READY(7) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.498 info (3320) Change state from STATE_READY(7) to STATE_DISCONNECT_RESPONSE(16) knx.0 2021-05-23 16:21:22.498 info (3320) ( END 1 ) Sending DISCONNECT_REQUEST_RESPONSE : 06 10 02 0a 00 08 12 00 ChID : 0 SeqCntIN : 17 SeqCntOUT : 58 msgCode : [object Object] knx.0 2021-05-23 16:21:22.496 info (3320) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 10 00 08 01 c0 a8 00 0a 0e 57 - ChannelID 16 SeqCntIN : 17 SeqCntOUT : 58 for 192.168.0.10:1487 knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_CONNECTION_STATE_RESPONSE(6) to STATE_READY(7) knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_CONNECTION_STATE_REQUEST(5) to STATE_CONNECTION_STATE_RESPONSE(6) knx.0 2021-05-23 16:21:21.495 info (3320) Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 10 00 192.168.0.10:3671 ChID : 16 SeqCntIN : 17 SeqCntOUT : 58 msgCode : [ knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_READY(7) to STATE_CONNECTION_STATE_REQUEST(5) knx.0 2021-05-23 16:21:21.495 info (3320) Send : conCheck Connection State Request : 06 10 02 07 00 10 10 00 08 01 00 00 00 00 d8 2b sent to 192.168.0.10:3671 knx.0 2021-05-23 16:21:21.494 info (3320) checkConnectionState 192.168.0.10 State : trueDas Muster ist immer Ähnlich, im Gutfall bekomme ich ein
Received TUNNEL_REQUEST (WRITE - send ACK )
im Schlechtfall ein
Received DISCONNECT_REQUEST -
Hallo,
nach Installation eines neuen KNX IP Interfaces ist die KNX Verbindung mit IOBroker sehr instabil. Ich habe Probleme dass Empfangstelegramme vom Bus nicht im Iobroker Objektbaum aktualisiert werden. Das Problem ist sporadisch, manchmal werden die Werte auch empfangen. Senden scheint okay zu sein.
ETS läuft ohne Verbindungsprobleme.
Mein Interface ist ein MDT SCN-IP000.03 IP Interface mit Secure.
ich verwende die aktuelle Version vom KNX Adapter 1.0.45.Hier mal ein Log von einen Gutfall:
knx.0 2021-05-23 16:19:20.849 info (3320) add to Buffer cnt: 58 : 06 10 04 20 00 16 04 10 06 00 11 00 bc e0 11 07 01 2d 02 00 80 8c queue.length : 0 GA : 0/1/45 knx.0 2021-05-23 16:19:20.848 info (3320) easy-knx.js groupValueWrite value: 55 dpt : DPT5.001{"type":"Buffer","data":[6,16,4,32,0,22,4,16,6,0,17,0,188,224,17,7,1,45,2,0,128,140]} knx.0 2021-05-23 16:19:20.847 info (3320) main.js : tGA.write on Statechange : 0/1/45 P-03DA-0_GA-421 typeof val: number 55 DPT5.001 knx.0 2021-05-23 16:19:20.825 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:19:20.825 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:19:20.825 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 0d 00 ChID : 16 SeqCntIN : 13 SeqCntOUT : 6 queue length : 0 knx.0 2021-05-23 16:19:20.824 info (3320) =====> STATE_TUNNELING_ACK knx.0 2021-05-23 16:19:20.823 info (3320) Change state from STATE_TUNNELLING_REQUEST(13) to STATE_TUNNELLING_ACK(14) knx.0 2021-05-23 16:19:20.823 info (3320) Change state from STATE_READY(7) to STATE_TUNNELLING_REQUEST(13) knx.0 2021-05-23 16:19:20.823 info (3320) WRITE : mappedName : UG Hobby Sollwert dest : 0/4/57 val: 55 (DPT5.001) UG_Hobby_Sollwert knx.0 2021-05-23 16:19:20.822 info (3320) ( 3.2 ) Received TUNNEL_REQUEST (WRITE - send ACK ) : 06 10 04 20 00 16 04 10 0d 00 29 00 bc e0 11 03 04 39 02 00 80 8c ChID: 16 knx.0 2021-05-23 16:19:20.394 info (3320) Change state from STATE_CONNECTION_STATE_RESPONSE(6) to STATE_READY(7) knx.0 2021-05-23 16:19:20.393 info (3320) Change state from STATE_CONNECTION_STATE_REQUEST(5) to STATE_CONNECTION_STATE_RESPONSE(6) knx.0 2021-05-23 16:19:20.393 info (3320) Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 10 00 192.168.0.10:3671 ChID : 16 SeqCntIN : 12 SeqCntOUT : 6 msgCode : [o knx.0 2021-05-23 16:19:20.392 info (3320) Change state from STATE_READY(7) to STATE_CONNECTION_STATE_REQUEST(5) knx.0 2021-05-23 16:19:20.392 info (3320) Send : conCheck Connection State Request : 06 10 02 07 00 10 10 00 08 01 00 00 00 00 d8 2b sent to 192.168.0.10:3671 knx.0 2021-05-23 16:19:20.391 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:19:20.391 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:19:20.391 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 0c 00 ChID : 16 SeqCntIN : 12 SeqCntOUT : 6 queue length : 0Und hier ein Schlechtfall:
knx.0 2021-05-23 16:21:25.034 info (3320) Change state from STATE_TUNNELLING_ACK(14) to STATE_READY(7) knx.0 2021-05-23 16:21:25.034 info (3320) ( 4.b ) return to STATE_READY, processing : false knx.0 2021-05-23 16:21:25.034 info (3320) ( 4 ) Sending Tunnel_Request ACK : 06 10 04 21 00 0a 04 10 00 00 ChID : 16 SeqCntIN : 0 SeqCntOUT : 0 queue length : 0 knx.0 2021-05-23 16:21:25.031 info (3320) =====> STATE_TUNNELING_ACK knx.0 2021-05-23 16:21:25.031 info (3320) Change state from STATE_TUNNELLING_REQUEST(13) to STATE_TUNNELLING_ACK(14) knx.0 2021-05-23 16:21:25.030 info (3320) Change state from STATE_READY(7) to STATE_TUNNELLING_REQUEST(13) knx.0 2021-05-23 16:21:25.030 info (3320) WRITE : mappedName : DG Nord Lichtwert dest : 9/0/15 val: 644.48 (DPT9.004) DG_Nord_Lichtwert knx.0 2021-05-23 16:21:25.029 info (3320) ( 3.2 ) Received TUNNEL_REQUEST (WRITE - send ACK ) : 06 10 04 20 00 17 04 10 00 00 29 00 bc e0 11 c9 48 0f 03 00 80 2f de ChID: 16 knx.0 2021-05-23 16:21:24.507 info (3320) Change state from STATE_CONNECT_RESPONSE(4) to STATE_READY(7) knx.0 2021-05-23 16:21:24.507 info (3320) Received CONNECTION_RESPONSE : 06 10 02 06 00 14 10 00 08 01 00 00 00 00 00 00 04 04 11 02 GW-IP: 192.168.0.10:3671 - ChannelID: 16 cnt IN/OUT: 0/0 knx.0 2021-05-23 16:21:24.506 info (3320) Change state from STATE_CONNECT_REQUEST(3) to STATE_CONNECT_RESPONSE(4) knx.0 2021-05-23 16:21:24.505 info (3320) Change state from STATE_PORT_OPENED(2) to STATE_CONNECT_REQUEST(3) knx.0 2021-05-23 16:21:24.505 info (3320) Send : UDP Connection Request : 06 10 02 05 00 1a 08 01 c0 a8 00 08 d9 ac 08 01 00 00 00 00 d9 ac 04 04 02 00 sent to 192.168.0.10:3671 knx.0 2021-05-23 16:21:24.505 info (3320) Connected - local UDP Server listening on 192.168.0.8:55724 knx.0 2021-05-23 16:21:24.505 info (3320) Change state from STATE_OPENING_PORT(1) to STATE_PORT_OPENED(2) knx.0 2021-05-23 16:21:24.505 info (3320) Event : UDP - listening knx.0 2021-05-23 16:21:24.504 info (3320) Change state from STATE_NOT_CONNECTED(0) to STATE_OPENING_PORT(1) knx.0 2021-05-23 16:21:24.504 info (3320) Using UDP with local IP: 192.168.0.8 knx.0 2021-05-23 16:21:22.522 info (3320) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.520 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.516 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.515 info (3320) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.515 info (3320) Received DISCONNECT_RESPONSE06 10 02 0a 00 08 10 21 knx.0 2021-05-23 16:21:22.514 info (3320) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed knx.0 2021-05-23 16:21:22.514 info (3320) Change state from STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) knx.0 2021-05-23 16:21:22.509 info (3320) STATE_NOT_CONNECTED : Stop connection : STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.509 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.506 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.505 info (3320) Change state from STATE_DISCONNECT_REQUEST(15) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.505 info (3320) STATE_DISCONNECT_REQUEST : no defined handling for transition from State: STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15). knx.0 2021-05-23 16:21:22.505 info (3320) Change state from STATE_DISCONNECT_RESPONSE(16) to STATE_DISCONNECT_REQUEST(15) knx.0 2021-05-23 16:21:22.504 info (3320) ( END ) Sending DISCONNECT_REQUEST : 06 10 02 09 00 10 10 00 08 01 c0 a8 00 08 d8 2b ChID : 0 SeqCntIN : 17 SeqCntOUT : 58 msgC knx.0 2021-05-23 16:21:22.504 info (3320) STATE_DISCONNECT_RESPONSE : from State: STATE_NOT_CONNECTED(0) to STATE_DISCONNECT_RESPONSE(16) ... connection closed knx.0 2021-05-23 16:21:22.503 info (3320) STATE_NOT_CONNECTED : Try to connect / reconnect : STATE_READY(7) to STATE_NOT_CONNECTED(0). knx.0 2021-05-23 16:21:22.503 info (3320) ... not able to close connection, because already closed knx.0 2021-05-23 16:21:22.499 info (3320) Connection persists.....closing now knx.0 2021-05-23 16:21:22.499 info (3320) Change state from STATE_READY(7) to STATE_NOT_CONNECTED(0) knx.0 2021-05-23 16:21:22.498 info (3320) Change state from STATE_READY(7) to STATE_DISCONNECT_RESPONSE(16) knx.0 2021-05-23 16:21:22.498 info (3320) ( END 1 ) Sending DISCONNECT_REQUEST_RESPONSE : 06 10 02 0a 00 08 12 00 ChID : 0 SeqCntIN : 17 SeqCntOUT : 58 msgCode : [object Object] knx.0 2021-05-23 16:21:22.496 info (3320) Received DISCONNECT_REQUEST: 06 10 02 09 00 10 10 00 08 01 c0 a8 00 0a 0e 57 - ChannelID 16 SeqCntIN : 17 SeqCntOUT : 58 for 192.168.0.10:1487 knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_CONNECTION_STATE_RESPONSE(6) to STATE_READY(7) knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_CONNECTION_STATE_REQUEST(5) to STATE_CONNECTION_STATE_RESPONSE(6) knx.0 2021-05-23 16:21:21.495 info (3320) Received CONNECTIONSTATE_RESPONSE : 06 10 02 08 00 08 10 00 192.168.0.10:3671 ChID : 16 SeqCntIN : 17 SeqCntOUT : 58 msgCode : [ knx.0 2021-05-23 16:21:21.495 info (3320) Change state from STATE_READY(7) to STATE_CONNECTION_STATE_REQUEST(5) knx.0 2021-05-23 16:21:21.495 info (3320) Send : conCheck Connection State Request : 06 10 02 07 00 10 10 00 08 01 00 00 00 00 d8 2b sent to 192.168.0.10:3671 knx.0 2021-05-23 16:21:21.494 info (3320) checkConnectionState 192.168.0.10 State : trueDas Muster ist immer Ähnlich, im Gutfall bekomme ich ein
Received TUNNEL_REQUEST (WRITE - send ACK )
im Schlechtfall ein
Received DISCONNECT_REQUEST@killroy2 Hast du eine extra Tunneladresse für den KNX Adapter eingetragen?
-
@killroy2 Hast du eine extra Tunneladresse für den KNX Adapter eingetragen?
@frankthegreat
Das IP Gateway hat die Adresse 192.168.0.10, die habe ich in der Adapterkonfiguration als KNX Gateway IP eingetragen.
Iobroker hat EIB PA 1.1.7
Das IP Interface die PA 1.1.1 und 1.1.6
Tunnel Kanal 1-4 geht auf 1.1.2-1.1.5
(Und auch wenn ich 1.1.5 testweise in der Adapterkonfiguration einstelle ist das Verhalten gleich.) -
@frankthegreat
Das IP Gateway hat die Adresse 192.168.0.10, die habe ich in der Adapterkonfiguration als KNX Gateway IP eingetragen.
Iobroker hat EIB PA 1.1.7
Das IP Interface die PA 1.1.1 und 1.1.6
Tunnel Kanal 1-4 geht auf 1.1.2-1.1.5
(Und auch wenn ich 1.1.5 testweise in der Adapterkonfiguration einstelle ist das Verhalten gleich.)@killroy2 Im Adapter muss in deinem Fall eine der Tunneladressen 1.1.2-1.1.5 eingestellt sein.
Diese darf auch von keinem anderem Gerät genutzt werden...auch nicht von der ETS.Viel Erfolg.
-
@frankthegreat
Das IP Gateway hat die Adresse 192.168.0.10, die habe ich in der Adapterkonfiguration als KNX Gateway IP eingetragen.
Iobroker hat EIB PA 1.1.7
Das IP Interface die PA 1.1.1 und 1.1.6
Tunnel Kanal 1-4 geht auf 1.1.2-1.1.5
(Und auch wenn ich 1.1.5 testweise in der Adapterkonfiguration einstelle ist das Verhalten gleich.)@killroy2 It's better to use 1.1.250 (or a similarly high number) for your IP Gateway.
As @frankthegreat writes, else you need to manually stop Devices from using the Tunnel addresses and as new devices usually get the first free lowest address automatically, you need to remember to change them or stop this to happen. Then it's easier to use the upper area to avoid those conflicts.
-
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
@garfonso sagte in Test Adapter KNX v1.0.x:
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
Wouldn't my feature request making this behaviour selectable be a solution to avoid those problems? https://github.com/ioBroker/ioBroker.knx/issues/160
-
Ich habe ein seltsames Problem: Ich versuche alle Rollos über ioBroker zu steuern. Etwa zwei Drittel funktioniert einwandfrei, das verbleibende Drittel funktioniert nicht. Ich kann leider nicht herausfinden woran es liegt. Hier die Gruppenadressen:
Bei den GAs, bei denen kein letzter Wert steht funktioniert es nicht. Es wird anstatt eines GroupValueWrite ein GroupValueRead gesendet.
Hier ein Beispiel eines Datenpunktes bei dem es funktioniert:
{ "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626475652, "common": { "name": "EG-Buero-Rollo-Fahren", "type": "boolean", "role": "", "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/2", "addressRefId": "P-0C17-0_GA-1140", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "MD-2_M-6_MI-1_O-2-23_R-4", "devName": "M-0083_A-0128-43-7CBD", "devInst": "P-0C17-0_DI-24", "objectSize": "" }, "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator", "state": 1636 }, "_id": "knx.0.Beschatten-1.Fahren.EG-Buero-Rollo-Fahren", "type": "state" }Und hier ein Beispiel bei dem es nicht funktioniert:
{ "_id": "knx.0.Beschatten-1.Fahren.OG-Ankleide-Rollo-Fahren", "type": "state", "common": { "name": "OG-Ankleide-Rollo-Fahren", "type": "boolean", "role": "value", "read": true, "write": true, "max": true, "min": false }, "native": { "dpt": "DPT1.008", "address": "6/0/16", "addressRefId": "P-0C17-0_GA-1154", "statusGARefId": "", "actGARefId": "", "update": "", "objRef": "O-5_R-11034", "devName": "M-0083_A-008A-27-4A49", "devInst": "P-0C17-0_DI-49", "objectSize": "" }, "from": "system.adapter.knx.0", "user": "system.user.admin", "ts": 1621626479292, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Ich weiß leider nicht, wo ich den Fehler noch suchen soll. Hat jemand eine Idee?
@markus84 What is your setting for the ETS Communication Flags for the Actor where "knx.0.Beschatten-1.Fahren.OG-Ankleide-Rollo-Fahren" is connected to?
-
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
@garfonso said in Test Adapter KNX v1.0.x:
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
Danke, deine Lösung funktioniert! Das Problem ist, dass ich jetzt aufpassen muss bei einem neuen Import das Häkchen bei "Add only new objects" zu setzen. Andernfalls würde er meine manuellen Anpassungen überschreiben. Das wäre dann eine Notlösung und ich würde gerne herausfinden, weshalb er manche GAs richtig erkennt und manche nicht. Die Flags sind nämlich völlig identisch. Auch das testweise Ändern des Namens der GA hat nichts gebracht.
@Videonisse
It is really strange why some GAs work and others don't. The flag settings are identical. As is everything else besides the name of the GA. Or at least I am not able to find out what else deviates.This GA does not work:
But this one works:
-
@garfonso said in Test Adapter KNX v1.0.x:
@markus84
Ja, du musst read auf false setzen, siehe auch hier: https://github.com/ioBroker/ioBroker.knx#3-herausfinden-der-schalt--und-statusaddressenDa wird leider oft quatsch gesetzt, wenn es keine Zuordnung von SchaltGA und StatusGA gibt.. theoretisch sollte sich das an den Flags im KNX Projekt orientieren. Die kannst du ja mal vergleichen.
Danke, deine Lösung funktioniert! Das Problem ist, dass ich jetzt aufpassen muss bei einem neuen Import das Häkchen bei "Add only new objects" zu setzen. Andernfalls würde er meine manuellen Anpassungen überschreiben. Das wäre dann eine Notlösung und ich würde gerne herausfinden, weshalb er manche GAs richtig erkennt und manche nicht. Die Flags sind nämlich völlig identisch. Auch das testweise Ändern des Namens der GA hat nichts gebracht.
@Videonisse
It is really strange why some GAs work and others don't. The flag settings are identical. As is everything else besides the name of the GA. Or at least I am not able to find out what else deviates.This GA does not work:
But this one works:
@markus84 For testing purposes, maybe you can install a second Instance of the KNX Adapter and import your project and verify if it is problem with the same GAs and compare some of the raw settings for the Objects?
Regarding import, maybe you can vote/like the issue?: https://github.com/ioBroker/ioBroker.knx/issues/157
(feel free to answer auf Deutsch :-) )
-
@markus84 For testing purposes, maybe you can install a second Instance of the KNX Adapter and import your project and verify if it is problem with the same GAs and compare some of the raw settings for the Objects?
Regarding import, maybe you can vote/like the issue?: https://github.com/ioBroker/ioBroker.knx/issues/157
(feel free to answer auf Deutsch :-) )
@frankthegreat @Videonisse
ich habe jetzt 1.1.250 fürs IP Interface und für die Tunneladressen 1.1.251..1.1.254 konfiguriert und jeweils testweise 1.1.251 und 1.1.254 in der IObroker Adaptereinstellung.
Das IP Interface sagt mir im Webinterface:
Tunneling Addresses 1. 1.251 UDP: 192.168.0.8- 1.254 not in use
Ergebnis ist ähnlich wie davor, die Anzahl der Disconnects ist jetzt bei ca. ein mal pro 10 Minuten im Schnitt.
Ich sehe jetzt noch ein Problem: wenn ich eine einzelne Gruppenadressen in der ETS auslese, kommt im Log sehr oft nichts an.
Im Log ist alle 10s ein checkConnectionState 192.168.0.10 State : true
Und ob ich eine oder eine reihe von Adressen auslese, im Log kommt keine Meldung. -
@frankthegreat @Videonisse
ich habe jetzt 1.1.250 fürs IP Interface und für die Tunneladressen 1.1.251..1.1.254 konfiguriert und jeweils testweise 1.1.251 und 1.1.254 in der IObroker Adaptereinstellung.
Das IP Interface sagt mir im Webinterface:
Tunneling Addresses 1. 1.251 UDP: 192.168.0.8- 1.254 not in use
Ergebnis ist ähnlich wie davor, die Anzahl der Disconnects ist jetzt bei ca. ein mal pro 10 Minuten im Schnitt.
Ich sehe jetzt noch ein Problem: wenn ich eine einzelne Gruppenadressen in der ETS auslese, kommt im Log sehr oft nichts an.
Im Log ist alle 10s ein checkConnectionState 192.168.0.10 State : true
Und ob ich eine oder eine reihe von Adressen auslese, im Log kommt keine Meldung.@killroy2
Jepp, die 1.1.250 ist fürs IP Interface...soweit ok.
Wenn aber die ETS eine Verbindung aufbaut, nimmt sie sich erstmal die 1.1.251.
Wenn du die 1.1.251 im Adapter fest hinterlegt hast, gibts da "Aussetzer".
Ich würde die 1.1.254 im Adapter einstellen.
Als nächstes mal schauen, ob das Secure-Geraffel im IP interface ausgeschaltet ist.Wieviel RAM hat dein Raspi? Nicht das der zu schwach auf der Brust ist :grinning:
-
@killroy2
Jepp, die 1.1.250 ist fürs IP Interface...soweit ok.
Wenn aber die ETS eine Verbindung aufbaut, nimmt sie sich erstmal die 1.1.251.
Wenn du die 1.1.251 im Adapter fest hinterlegt hast, gibts da "Aussetzer".
Ich würde die 1.1.254 im Adapter einstellen.
Als nächstes mal schauen, ob das Secure-Geraffel im IP interface ausgeschaltet ist.Wieviel RAM hat dein Raspi? Nicht das der zu schwach auf der Brust ist :grinning:
@frankthegreat Der Raspi hat 4G und davon 50% frei. Da es mit einem anderen IP Interface mal funktionierte schließe ich den eher aus. IP Secure und alles hinderliche ist deaktiviert. Es ist ein MDT SCN-IP000.03 mit neuester Firmware. Es schein andere Hersteller zu geben mit baugleicher Hardware. Gibts erfahrung das dass Interface generell mit IOBroker tut?
Support us
382
Online32.4k
Users81.5k
Topics1.3m
Posts