NEWS
Test Adapter OpenKNX 0.6.x
-
Hallo,
nach einem Restart des Raspberry über die Console bekomme ich wieder folgende Fehlermeldungen im Log:2022-02-19 09:05:41.851 - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 started with pid 688 2022-02-19 09:05:44.832 - [32minfo[39m: openknx.0 (688) starting. Version 0.1.19 in /opt/iobroker/node_modules/iobroker.openknx, node: v14.19.0, js-controller: 4.0.8 2022-02-19 09:05:44.870 - [32minfo[39m: openknx.0 (688) Connecting to knx gateway: 10.10.20.2:3671 with phy. Adr: 1.1.253 minimum send delay: 50 ms 2022-02-19 09:05:44.872 - [32minfo[39m: openknx.0 (688) /opt/iobroker/node_modules/iobroker.js-controller 2022-02-19 09:05:45.213 - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.157 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64) at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1) at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11) at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14) at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1) at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10) at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14) at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1) at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1) at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 0610020800089300 2022-02-19 09:05:45.222 - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.220 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64) at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1) at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11) at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14) at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1) at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10) at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14) at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1) at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1) at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 061004200019049301002900bce011fe240805008040f9999a 2022-02-19 09:05:45.236 - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:05:45.234 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefinedScheinbar hat der Adapter ab und zu Probleme sich bei einem Neustart des RPi richtig zu verbinden. Wenn ich den Adapter dann manuell über die WebPage neu starte gibt es anschließend keine Probleme mehr und der Adapter läuft ohne Probleme.
2022-02-19 09:54:02.013 - [32minfo[39m: host.raspberrypi "system.adapter.openknx.0" disabled 2022-02-19 09:54:02.029 - [32minfo[39m: host.raspberrypi stopInstance system.adapter.openknx.0 (force=false, process=true) 2022-02-19 09:54:02.059 - [31merror[39m: openknx.0 (688) [error] 2022-02-19 08:54:02.058 (idle): Incomplete/unparseable UDP packet: TypeError: Cannot read property 'current_value' of undefined at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:505:64) at fsm.<anonymous> (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:27:1) at arrayEach (/opt/iobroker/node_modules/lodash/lodash.js:530:11) at Function.forEach (/opt/iobroker/node_modules/lodash/lodash.js:9410:14) at fsm.emit (/opt/iobroker/node_modules/machina/lib/webpack:/src/emitter.js:25:1) at fsm.emitEvent (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:602:10) at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:552:14) at fsm.transition (/opt/iobroker/node_modules/machina/lib/webpack:/src/BehavioralFsm.js:175:1) at fsm.Fsm.<computed> [as transition] (/opt/iobroker/node_modules/machina/lib/webpack:/src/Fsm.js:80:1) at fsm.inbound_TUNNELING_REQUEST_L_Data.ind (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:340:16): 06100420001504936f002900bce011fe244d010080 2022-02-19 09:54:02.086 - [32minfo[39m: openknx.0 (688) Got terminate signal TERMINATE_YOURSELF 2022-02-19 09:54:02.087 - [32minfo[39m: host.raspberrypi stopInstance system.adapter.openknx.0 send kill signal 2022-02-19 09:54:02.088 - [32minfo[39m: openknx.0 (688) terminating 2022-02-19 09:54:02.090 - [32minfo[39m: openknx.0 (688) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2022-02-19 09:54:02.687 - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2022-02-19 09:58:10.065 - [32minfo[39m: host.raspberrypi "system.adapter.openknx.0" enabled 2022-02-19 09:58:10.346 - [32minfo[39m: host.raspberrypi instance system.adapter.openknx.0 started with pid 1625 2022-02-19 09:58:12.435 - [32minfo[39m: openknx.0 (1625) starting. Version 0.1.19 in /opt/iobroker/node_modules/iobroker.openknx, node: v14.19.0, js-controller: 4.0.8 2022-02-19 09:58:12.475 - [32minfo[39m: openknx.0 (1625) Connecting to knx gateway: 10.10.20.2:3671 with phy. Adr: 1.1.253 minimum send delay: 50 ms 2022-02-19 09:58:12.476 - [32minfo[39m: openknx.0 (1625) /opt/iobroker/node_modules/iobroker.js-controller 2022-02-19 09:58:13.319 - [32minfo[39m: openknx.0 (1625) Connected! 2022-02-19 09:58:13.788 - [32minfo[39m: openknx.0 (1625) Found 934 valid KNX objects of 936 objects in adapter.@chrischros said in Test Adapter OpenKNX 0.1.x:
Hast du mehrere Adapterinstanzen laufen? Was für ein KNX Gateway besitzt du?
Für mich sieht es so aus dass das Gateway ein recvTunnReqIndication schickt, noch bevor ein connect
erfolgt ist und davon einen event auslöst. Meine Logik vertraut aber auf diese Sequenz. Und ich seh auch nicht dass der connect nachgeholt wird. Die Library ist in einem inkonsistenten Zustand.Ich kann es jetzt sogar nachstellen wenn ich 2 Adapterinstanzen laufen lasse. Ich teste einen Workaround oder Patche die Lib. Kommt dann in 0.1.21
-
@killroy2, @Tontechniker : Bei euch funktionieren die Beleuchtungsaktoren ohne Probleme?
Ich hätte jetzt erwartet, dass der DPT 1.001 das Allereinfachste ist, irgendwie komisch.@netfriend Ich hab dich so verstanden dass bei dir garnichts ausgangsseitig geht. Wenn da outbound kommt, dann ist im IOB eigentlich alles io. Du kannst noch ein silly Log machen um zu sehen ob noch mehr kommt.
-
@netfriend Ich hab dich so verstanden dass bei dir garnichts ausgangsseitig geht. Wenn da outbound kommt, dann ist im IOB eigentlich alles io. Du kannst noch ein silly Log machen um zu sehen ob noch mehr kommt.
@killroy2 Ich hab noch etwas probiert.
Also es ist wohl so:
Ich habe ein IP-Interface Weinzierl 732 secure (das secure-Feature ist aktuell deaktiviert). Dieses ermöglicht bis zu 8 Verbindungen gleichzeitig, über LEDs sieht man am Gerät welche Verbindungen belegt sind. Das passt alles soweit.
Verwende ich dieses Gateway mit dem KNX-Adapter, funktioniert auch das Licht schalten.
Mit dem openKNX-Adapter funktioniert das Schalten nicht. Im silly-Log sehe ich folgendes:
Allerdings sehe ich in der ETS -entgegen dem was ich vorhin geschrieben habe- tatsächlich das passende Telegramm:
Trotzdem schaltet der Aktor nicht wie gewünscht.
Nun habe ich noch ein altes (Reserve) Gateway Weinzierl 730. Nun habe ich dieses nochmal angeschlossen, kurz die IP im Adapter geändert und siehe da, der Aktor schaltet. Das Log zeigt folgendes:
Ich verstehe gerade nicht, was das mit der Hardware zu tun haben soll. Viel konfigurieren kann man da nicht. Mehrere Hundert GAs werden auch korrekt dargestellt (Zustände, Messwerte).
-
@chrischros said in Test Adapter OpenKNX 0.1.x:
Hast du mehrere Adapterinstanzen laufen? Was für ein KNX Gateway besitzt du?
Für mich sieht es so aus dass das Gateway ein recvTunnReqIndication schickt, noch bevor ein connect
erfolgt ist und davon einen event auslöst. Meine Logik vertraut aber auf diese Sequenz. Und ich seh auch nicht dass der connect nachgeholt wird. Die Library ist in einem inkonsistenten Zustand.Ich kann es jetzt sogar nachstellen wenn ich 2 Adapterinstanzen laufen lasse. Ich teste einen Workaround oder Patche die Lib. Kommt dann in 0.1.21
@killroy2 said in Test Adapter OpenKNX 0.1.x:
Hast du mehrere Adapterinstanzen laufen? Was für ein KNX Gateway besitzt du?
Deinen openKNX-Adapter habe ich nur einmal laufen. Als KNX Gateway nutze ich das Enertex KNX IP Secure Interface.
Mit diesem kann habe ich die Möglichkeit 8 Tunnel anzulegen wovon ich 3 nutze. Den erste Tunnel nutze ich für die ETS, den zweiten für Edomi (Hausautomation) und den dritten für den openKNX-Adapter. -
@killroy2 Ich hab noch etwas probiert.
Also es ist wohl so:
Ich habe ein IP-Interface Weinzierl 732 secure (das secure-Feature ist aktuell deaktiviert). Dieses ermöglicht bis zu 8 Verbindungen gleichzeitig, über LEDs sieht man am Gerät welche Verbindungen belegt sind. Das passt alles soweit.
Verwende ich dieses Gateway mit dem KNX-Adapter, funktioniert auch das Licht schalten.
Mit dem openKNX-Adapter funktioniert das Schalten nicht. Im silly-Log sehe ich folgendes:
Allerdings sehe ich in der ETS -entgegen dem was ich vorhin geschrieben habe- tatsächlich das passende Telegramm:
Trotzdem schaltet der Aktor nicht wie gewünscht.
Nun habe ich noch ein altes (Reserve) Gateway Weinzierl 730. Nun habe ich dieses nochmal angeschlossen, kurz die IP im Adapter geändert und siehe da, der Aktor schaltet. Das Log zeigt folgendes:
Ich verstehe gerade nicht, was das mit der Hardware zu tun haben soll. Viel konfigurieren kann man da nicht. Mehrere Hundert GAs werden auch korrekt dargestellt (Zustände, Messwerte).
@netfriend Wenn die Daten korrekt in der ETS ankommen dann kann es schon nicht am Adapter liegen. Mach mal einen Diff was in der ETS angezeigt wird. Im trace schickst du verschiedene Werte, nicht dass es daran liegt.
-
@netfriend Wenn die Daten korrekt in der ETS ankommen dann kann es schon nicht am Adapter liegen. Mach mal einen Diff was in der ETS angezeigt wird. Im trace schickst du verschiedene Werte, nicht dass es daran liegt.
@killroy2 Ich bin mir noch nicht sicher, ob die Daten korrekt ankommen. Im ersten Moment sah es so aus, jedenfalls im Gruppenmonitor.
Nun habe ich es nochmal probiert und mir auch in den Eigenschaften die Raw-Data angesehen. Diese sind tatsächlich unterschiedlich:Weinzierl 732 secure:
Weinzierl 730:
Das würde ja mit mit den unterschiedlichen Daten im trace zusammenpassen. Nun stellt sich mir die Frage, warum schickt der openKNX-Adapter bei der gleichen Aktion (Aktor-Element Schieber auf "true" und bestätigen) unterschiedliche Telegramme, wenn man zwischendurch lediglich die IP des Gateways ändert und denn Adapter wieder startet? Ich versteh's nicht....
-
@killroy2 Noch ein anderer Versuch: Openknx- und KNX-Adapter beide mit Weinzierl 732 secure-Interface.
Ergebnis: KNX-Adapter schaltet Aktor, Openknx nicht.Hier die Logs und ETS vom funktionierenden KNX-Adapter:
Hier die Logs und ETS vom nicht funktionierenden OpenKNX-Adapter:
Für mich sieht es irgendwie so aus, als ob beide Adapter unterschiedliche Telegramme schicken, was zu unterschiedlichen Ergebnissen führt - bei gleichem IP-Interface.
Im vorherigen Post sieht man, das der OpenKNX-Adapter auch unterschiedliche Telegramme bei verschiedenen IP-Interfaces schickt.
Daher vermute ich ein Problem zwischen OpenKNX und den div. IP-Interfaces. Was weiß OpenKNX von den IP-Interfaces bzw. warum und wie reagiert der Adapter dahingehend, dass andere Telegramme gesendet werden?
-
@netfriend warum schickt er auf verschiedenen Quelladdressen wenn du das selbe KNX Gateway verwendest - was ist im Dialog von OpenKnx eigestellt?
-
@netfriend warum schickt er auf verschiedenen Quelladdressen wenn du das selbe KNX Gateway verwendest - was ist im Dialog von OpenKnx eigestellt?
Im OpenKNX-Dialog sieht es so aus:
.Hier ändere ich lediglich die IP von .222 (Weinzierl 730) auf .223 (Weinzierl 732 secure).
Beim 732 gibt es insgesamt 8 IP-Verbindungen. In der ETS ist das 732 mit der phy. Adresse 1.1.200 angelegt und die 8 Verbindungen bekommen die 1.1.201-1.1.208. Bei Herstellen der Verbindung wird wohl die erste freie Adresse verwendet. In diesem Fall war es die 1.1.205
Ist für mich nachvollziehbar.
Das 730 bietet 5 IP-Verbindungen. In der ETS sehe ich die verwendeten Adressen:
Warum diese nicht im Gruppenmonitor angezeigt wird, weiß ich nicht. Hier sieht man nach wie vor die im Adapter eingestellte phy. Adresse.
Insgesamt ist das für mich stimmig. Zumal der Empfang ja immer geht.
-
Im OpenKNX-Dialog sieht es so aus:
.Hier ändere ich lediglich die IP von .222 (Weinzierl 730) auf .223 (Weinzierl 732 secure).
Beim 732 gibt es insgesamt 8 IP-Verbindungen. In der ETS ist das 732 mit der phy. Adresse 1.1.200 angelegt und die 8 Verbindungen bekommen die 1.1.201-1.1.208. Bei Herstellen der Verbindung wird wohl die erste freie Adresse verwendet. In diesem Fall war es die 1.1.205
Ist für mich nachvollziehbar.
Das 730 bietet 5 IP-Verbindungen. In der ETS sehe ich die verwendeten Adressen:
Warum diese nicht im Gruppenmonitor angezeigt wird, weiß ich nicht. Hier sieht man nach wie vor die im Adapter eingestellte phy. Adresse.
Insgesamt ist das für mich stimmig. Zumal der Empfang ja immer geht.
@netfriend ich mein was ist im OpenKnx Admin Dialog eingestellt?
-
@netfriend ich mein was ist im OpenKnx Admin Dialog eingestellt?
@killroy2 sagte in Test Adapter OpenKNX 0.1.x:
@netfriend ich mein was ist im OpenKnx Admin Dialog eingestellt?
Ist das nicht der Dialog, den ich oben eingefügt habe? Dann weiß ich nicht, wo ich den finde.
-
@killroy2 sagte in Test Adapter OpenKNX 0.1.x:
@netfriend ich mein was ist im OpenKnx Admin Dialog eingestellt?
Ist das nicht der Dialog, den ich oben eingefügt habe? Dann weiß ich nicht, wo ich den finde.
@netfriend was ich nicht verstehe ist warum im Dialog 1.1.150 eingestellt ist, aber im zweiten Trace mit dem 732 die Quelladresse 1.1.205 kommt,
im ersten Trace übernimmt das 730 Gateway die 1.1.150 (und damit geht es), der 732 anscheinend nicht.
Setzte doch mal die richte Addresse und teste nochmal. -
Ich habe auch Probleme mit dem Weinzierl 732, mit dem NodeRed Ultimate trat der gleiche Fehler auf. Die Lösung für das Problem liegt wohl in der supress ACK Funktion des NodeRed Ultimate.
https://github.com/Supergiovane/node-red-contrib-knx-ultimate/issues/78 -
@dachauan Danke für den Link. Das erklärt mein Problem. Das Verhalten hat mir gestern auch der Weinzierl-Support bestätigt
@killroy2 Ich habe gestern mein Verhalten dem Weinzierl-Support geschildert, mit der Fragestellung ob es nur durch Tausch der beiden Geräte zu diesem Verhalten kommen kann. Könntest Du dir das bitte ansehen, ich vermute das ist ein Bug in openKNX.
Die Antwort des Weinzierl-Supports lautete:
Bezüglich der RawData:
730: 29 00 BC E0 11 96 55 00 01 00 81 Source address: 1.1.150
732: 29 00 BE E0 11 CA 55 00 01 00 81 Source address: 1.1.202BC ist korrekt.
BE dürfte es in KNX nicht geben.Das BE kommt zustande, da Bit 1 in diesem Byte gesetzt ist. Dies entspricht bei common EMI dem „acknowledge request“ flag.
Vermutlich setzen Sie dieses Bit (acknowledge request) fälschlicherweise irgenwo in Ihrem RaspberryPi4 mit IoBroker und dem openKNX-Adapter.Unser 730 filtert diesen Fehler raus – Unser 732 leider nicht.
Ich gehe davon aus, dass das Telegramm in openKNX „falsch“, bzw. mit gesetztem AcknowledgeRequest Flag gebaut wird.
Unser 730 filtert dies heraus und sendet das „korrigierte“ Telegramm weiter.Antwort Ende
Und das ist auch das, was ich sehe. Der selbe Versuch mit dem KNX-Adapter und dem Weinzierl 732 sendet BC und dann schaltet auch der Aktor.
-
In der Connection.js (ioBroker.openknx/blob/master/lib/knx/src/Connection.js) kann man den ACK Request unterdrücken. Evtl. wäre ein Option in der Adapterkonfig nicht schlecht, ähnlich der Umsetzung im NodeRed KNX Ultimate.
@dachauan sagte in Test Adapter OpenKNX 0.1.x:
In der Connection.js (ioBroker.openknx/blob/master/lib/knx/src/Connection.js) kann man den ACK Request unterdrücken. Evtl. wäre ein Option in der Adapterkonfig nicht schlecht, ähnlich der Umsetzung im NodeRed KNX Ultimate.
Ja, das wäre bestimmt sinnvoll.
-
@dachauan sagte in Test Adapter OpenKNX 0.1.x:
In der Connection.js (ioBroker.openknx/blob/master/lib/knx/src/Connection.js) kann man den ACK Request unterdrücken. Evtl. wäre ein Option in der Adapterkonfig nicht schlecht, ähnlich der Umsetzung im NodeRed KNX Ultimate.
Ja, das wäre bestimmt sinnvoll.
@netfriend
Bei mir gehts jetzt.
Probiers mal aus, ist jetzt nur hard coded drin, muss man mal konfigurierbar machen.
Vielleicht hab ich nächste Woche mal Zeit.
https://github.com/dachauan/ioBroker.openknx -
@netfriend
Bei mir gehts jetzt.
Probiers mal aus, ist jetzt nur hard coded drin, muss man mal konfigurierbar machen.
Vielleicht hab ich nächste Woche mal Zeit.
https://github.com/dachauan/ioBroker.openknx -
@netfriend Im iobroker den Expertenmodus aktivieren, dann im Tab Adapters auf das Github Symbol klicken, Benutzerdefiniert auswählen und die Url aus meinem Post verwenden.
Support us
863
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge