Test Adapter OpenKNX 0.6.x

[netfriend]

@killroy2 Leider nicht. Nachdem das nur alle paar Monate vorkommt, ist das äußerst schwierig. Hab die iobroker logs auf debug gestellt, aber wirklich weiter hat es mich auch nicht gebracht. Und die ETS läuft nicht permanent mit. Reproduzieren kann ich es auch nicht, weil ich eben nicht weiß, welcher Wert gerade geschrieben werden sollte oder unter welchen Umständen das passiert.

[Markus84]

@killroy2 ich habe das gleiche Problem wie @netfriend. Bei mir tritt es aber etwas häufiger auf. Gewollt reproduzieren kann ich es leider auch nicht. Meine Lösung ist ein KNX Gerät jede Minute ein Signal in eine Gruppenadresse schreiben zu lassen. Wurde die Gruppenadresse 2 Minuten nicht aktualisiert, wird der Adapter automatisch neu gestartet. Schön ist das nicht, denn bis alle GAs aktualisiert sind geht erst mal 2 Minuten gar nichts… Eine robustere Version wäre daher wirklich super. Danke für deine tolle Arbeit!

[netfriend]

@markus84 So ähnlich habe ich das auch gelöst, und wenn mein Heartbeat-Signal eine gewisse Zeit ausbleibt, sende ich mir eine Nachricht, damit ich das weiß und gezielt im log suchen kann. Bisher aber ohne nennenswerte Erkenntnis.
Kann man aus nem Blockly den Adapter neu starten?

[Tontechniker]

@killroy2 Wäre es nicht sinnvoller, weitere Fehlersuche/Tests mit der V0.2.7 durchzuführen. Seit der V0.1.22 hat sich doch einiges geändert/verbessert und vielleicht tritt dann der Fehler nicht mehr auf und Du sparst Dir die Zeit der Fehlersuche?

[Markus84]

@netfriend Ja das kann man. Einfach unter system.adapter.[Adaptername].0.alive (ggf. noch Instanz anpassen) von true auf false umschaltet und wieder zurück.

[netfriend]

@markus84 Danke, nachdem ich in den Expertenmodus geschaltet habe, sehe ich auch den Eintrag.
Hab davor ewig gesucht

[killroy2]

@markus84 Ich baue in die kommende Version eine Logging Funktion ein, was zumindest die Fehlersuche unterstützt. Version kommt in den nächsten Tagen mit weiteren Verbesserungen.

[Markus84]

@killroy2 Das ist wirklich super, besten Dank!

[Finkinho]

Hallo,
ich nutze den Adapter (0.2.5) seit einigen Wochen und möchte mich zunächst für die tolle Arbeit bedanken!

Nun stehe ich vor einem Problem, dass bestimmte Objekte nicht gesschrieben werde; in diesem Fall Rückmeldungs-GAs von verschiedenen Steckdosen. Andere wiederum funktionieren.

Hier einmal ein Beispiel, bei dem es funktioniert:

und hier ein Beispiel, bei es nicht funktioniert:

Mir fällt auf, dass die Zeile "from" abweicht. In dem Fall, wo es nicht funtkioniert, ist dort "admin" angegeben, im anderen Fall "openknx". Wenn ich dies auf openknx ändere und abspeichere, wird es wieder mit admin überschrieben.
Im Gruppenmonitor der ETS5 kann ich sehen, dass die Status-GAs geschrieben werden, nur werden einzelne Objekte nicht geschrieben. Die Flags und DPTs in den verschiedenen Status GAs sind alle gleich.

Kann es damit zusammenhängen, dass ich nach einer ersten Installation des Adapaters Aliase erstellt habe? Diese habe ich im Nachgang im Objektbaum direkt gelöscht, sowie auch die Instanz. Nach Neuistallation des Adapters wollte ich hier ohne Aliase starten.

Danke vorab!

[killroy2]

@finkinho Das from und timestamp kommt von deinem edit. Ich sehe einen unterschied bei role switch.
Was kommt im Log beim Empfang der beiden Objekte und wie sehen die Empfangsobjekte aus wenn du über Wert des Objekts hoverst?

[blauholsten]

Hallo,

@killroy2

ich bin gerade dabei ein ETS Programm in den Adapter einzulesen, aktuelle habe ich noch keine Verbindung zur eigentlichen Hardware (Fehlender Zugang). Das einlesen der DP hat top funktioniert, jedoch was für mich sehr wichtig ist, die automatischer Erstellung von Aliase hat nicht geklappt. Ich habe jetzt stundenlang versucht, den Fehler bei mir zu finden, leider ohne Erfolg. Dann habe ich angefangen den Adapter etwas zu Debuggen, dabei viel mir auf, das beim Versuch zum erzeugen der Aliase die "gaList" leer ist. Nun meine Frage, ist meine Vermutung richtig, dass dies erst mit einer Verbindung zur Hardware möglich ist? Falls ja, gibt es dafür einen Grund?

[killroy2]

@blauholsten du kannst die stelle auskommentieren wo auf !this.config.gwip geprüft wird. Ich muss an einer Stelle verhindern dass der Stack gestartet wird und hatte deinen use case nicht im Sinn. In der nächsten Version kann ich es ändern.

[Finkinho]

@killroy2 Guten Abend, war ein paar Tage off, sorry. Danke für deine schnelle Rückmeldung.

Bei Hovern erhalte ich:
Wert: (null)
Bestätigt: true
Zeitstempel 17.11.
Zuletzt geändert: 06.11.
Von: openknx.0
Benutzer: admin
Qualität: 0x00 good

Folgendes bekomme ich aus dem Log für eine GA (Mähroboter), bei der das Status-Objekt nicht geschrieben wird (erst das Log der Schalten GA 2.1.23, dann kommt die Status-GA 2.2.23:

2022-11-17 12:49:36.857 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.857 2022-11-17 11:49:36 **** (2/1/23) false DATAPOINT CHANGE (was: true)
2022-11-17 12:49:36.857 - debug: openknx.0 (19479) Inbound GroupValue_Write from 1.1.243 GA 2/1/23 to Object: openknx.0.Steckdosen.Ein_Aus.A04_Garten_Außensteckdose_Süd_Mähroboter val: false dpt: DPT1.001
2022-11-17 12:49:36.858 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.858 (idle): UDP sent OK: TUNNELING_ACK 06100421000a0413ae00
2022-11-17 12:49:36.881 - silly: openknx.0 (19479) States user redis pmessage openknx.0.*/openknx.0.Steckdosen.Ein_Aus.A04_Garten_Außensteckdose_Süd_Mähroboter:{"val":false,"ack":true,"ts":1668685776870,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1668685776870}
2022-11-17 12:49:36.969 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:36.969 Inbound message: 0610042000150413af002900bce011011217010080
2022-11-17 12:49:36.969 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.969 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":19,"seqnum":175,"rsvd":0},"cemi":{"msgcode":41,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"1.1.1","dest_addr":"2/2/23","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,128]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[0]}}}}
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 (recvTunnReqIndication): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":19,"tunnel_endpoint":"192.168.1.74:3671","seqnum":175}}
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:36.970 (idle): zzzz...
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 2022-11-17 11:49:36 **** (2/2/23) false DATAPOINT CHANGE (was: true)
2022-11-17 12:49:36.970 - debug: openknx.0 (19479) receive self ga: 1.1.1
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 (idle): UDP sent OK: TUNNELING_ACK 06100421000a0413af00
2022-11-17 12:49:40.829 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:40.829 Inbound message: 0610042000150413b0002900bce011f31118010081
2022-11-17 12:49:40.831 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:40.830 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":19,"seqnum":176,"rsvd":0},"cemi":{"msgcode":41,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"1.1.243","dest_addr":"2/1/24","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,129]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[1]}}}}
2022-11-17 12:49:40.832 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:40.831 (recvTunnReqIndication): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":19,"tunnel_endpoint":"192.168.1.74:3671","seqnum":176}}
2022-11-17 12:49:40.832 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:40.832 (idle): zzzz...

[killroy2]

@finkinho
Wird das Statusobjekt in der ETS im Gruppenmonitor grün angezeigt?
Es fehlt die Indication, weil kein Empfänger registriert ist und die Message generiert. Der Adapter wird den Sendevorgang dann als fehlgeschlagen bewerten.

[Finkinho]

@killroy2 Hi, stehe etwas auf dem Schlauch. Grün wird mir dort nichts angezeigt. Hier ein Ausschnitt aus dem Gruppenmonitor, in diesem Falle geschaltet aus dem iobroker heraus. Die Status- GA in der ETS bekommt dann den richtigen Wert. Im Objekt im iobroker kommt aber nichts an.

Grüße

[killroy2]

@finkinho ok verstehe deinen Aufbau. Hold dir die Version 0.2.6 oder neuer, damit ist das Problem adressiert.

[leachim200]

Hi,
ich teste den Adapter nun seit ein paar Tagen finde ihn echt super und stabil.

Das einzige was ich mir noch wünschen würde wäre das er KNX Secure also bspw.: MDT Secure unterstützt sodass ich das Secure vom mdt ip gateway 003 verwenden kann

[killroy2]

Version 0.3.2 ist verfügbar seit ein paar Tagen (2022-11-20) auf dem Beta Repository.
Es läuft soweit stabil in meiner Hausinstallation.
Was hat sich getan seit dem letzten Release 0.2.7?

• feature: sync knx library
• feature: sync with create adapter 0.2.3
• feature: update to newer versions of dependant packages
• feature: setting autoreadEnabled autoread
• bugfix: allow alias generation with missing gateway configuration
• bugfix in knx lib: keep correct order of send datagrams in case of burst write

[Finkinho]

@killroy2 Nach Update auf 0.2.6 funktioniert's jetzt, vielen Dank!

[Markus84]

@killroy2 Danke für die neue Version!

Bei mir kam es nach dem Update zu einem seltsamen Verhalten. Ein Schaltbefehl hat weit über eine halbe Minute gedauert. Ein Neustart des Adapters hat keine Abhilfe gebracht. Nach einem Neustart des gesamten Systems schein alles wie gewohnt zu funktionieren.

Mir ist im Log noch ein Fehler bei mir aufgefallen (openknx.0.xxx has assigned a non exclusive group adddress: 10/1/19). Wie kann ich denn die zweite GA mit dieser Adresse finden? Oder verstehe ich die Fehlermeldung falsch?