Test Adapter OpenKNX 0.6.x

[killroy2]

@chrischros
Schau mal nach ob ein Empfänger für 4/5/6 in deiner ETS konfiguriert ist. Der sollte das quittieren. Wenn nicht ist was falsch oder es wird irrelevante Information auf den Bus gelegt.
Ich habe den Adapter jetzt etwas kommunikativer gemacht und ein paar Dinge auf Info gelegt. Das hilft die Installation aufgeräumt zu halten.

[ChrisChros]

@killroy2 bei dieser Adresse handelt es sich um Daten die von einem ioBroker-Adapter auf den Bus geschrieben werden. Ich nutze dazu ein kleines Blockly-Script:

In der ETS sind die entsprechenden GAs über eine Dummy Applikation wie folgt angelegt:

Als Flags wurden nur K,L und Ü angelegt. Da die GA mit einem Dummy verbunden ist glaube ich nicht das dort eine Quitierung erfolgen kann.

[killroy2]

@chrischros Ok, aber warum legt du Daten auf einen Kommunikationsbus für die es keine Empfänger gibt?
Btw. es gibt ein Update 0.5.1 was einen Fehler mit der Anzeige von confirmation false behebt.

[killroy2]

@tontechniker Vielen Dank dir und auch allen ein gutes Neues Jahr 2023!
Der Adapter ist nach ein paar mittelgrossen Änderungen wieder stabil und läuft bei mir im Dauertest soweit unauffällig. Wenn nichts mehr hochkommt werde ich den Adapter bald in den Stable Bereich überführen.

[ChrisChros]

@killroy2 Hauptsächlich nutze ich die Software Edomi zur Steuerung der Hausautomation. ioBroker und den KNX Baustein nutze ich um gewisse IOT-Geräte auf den KNX-BUS zubringen für die es keine gescheite Anbindung in Edomi gibt.
Die dadurch bereitgestellten Daten werden dann in Edomi für z.B. Logiken und die Visu weiterverwendet. Somit gibt es schon einen Empfänger aber keine richtiges ETS Gerät.

[killroy2]

@chrischros Ok, dein Edomi schneidet nicht nur den Busverkehr mit sondern du setzt KNX als
Backbone für deine Visualisierung ein. Warum gehst du über den Umweg KNX - beide sind doch auch im Netzwerk?
Da die Visu seine extra Telegramme nicht bestätigt hast du immer 4 (?) Sendeversuche.

[ChrisChros]

@killroy2 sagte in Test Adapter OpenKNX 0.2.x:

Warum gehst du über den Umweg KNX - beide sind doch auch im Netzwerk?

z.B. ist die Anbindung meiner Solarthermieanlage in Edomi nicht wirklich gut. Diese Werte nutze ich aber noch in der Logikengine zur Heizungssteuerung.
Des Weiteren ist die Anbindung an influxdb deutlich einfacher als über Edomi.

@killroy2 sagte in Test Adapter OpenKNX 0.2.x:

Da die Visu seine extra Telegramme nicht bestätigt hast du immer 4 (?) Sendeversuche.

Wie meinst du das mit den 4 Sendeversuchen?
Die Werte werden ganz normal auf eine GA geschrieben, die dann von Edomi für Logik und / oder Visu verwendet wird.
Dadurch das dort kein Aktor eingebunden ist kann auch nichts bestätigt werden. Edomi lauscht nur auf dieser GA.

[netfriend]

@killroy2 sagte in Test Adapter OpenKNX 0.2.x:

Da die Visu seine extra Telegramme nicht bestätigt hast du immer 4 (?) Sendeversuche.

Ist das ein Problem?
Jede Visu hört auf GAs die oft keinen physikalischen Empfänger haben.
Egal ob kommerzielle KNX-Geräte (z.B. Jalousie-Status) oder ein Raspi, der Temperaturen misst und diese auf den Bus sendet (z.B. VL-,RL-Temperaturen der Heizung oder Solarthermie), nutze ich diese zur Visu (CometVisu) oder speichere diese in InfluxDB zur Analyse.

[killroy2]

@chrischros said in Test Adapter OpenKNX 0.2.x:

Wie meinst du das mit den 4 Sendeversuchen?
Die Werte werden ganz normal auf eine GA geschrieben, die dann von Edomi für Logik und / oder Visu verwendet wird.
Dadurch das dort kein Aktor eingebunden ist kann auch nichts bestätigt werden. Edomi lauscht nur auf dieser GA.

Das IP Interface quittiert alle Eingangstelegramme auf dem Bus sobald ein Tunnel geöffnet ist.
Ich vermute du hast ein Interface mit mehreren Tunneln konfiguriert. Der IOBroker Tunnel schickt und das Interface quittiert sich seine eigenen Telegramme nicht selber. Der Adapter zeigt dir das an.

[ChrisChros]

@killroy2 danke für die Erklärung.
Und diese Meldung kommen weil der Adapter seit dem letzten Update kommunikativer ist?
Bei den älteren Versionen sind diese Meldungen nie aufgelaufen.

[killroy2]

@chrischros
Ja richtig, die Info kommt erst seit den letzten Updates.

Ich lag falsch, bei zwei offenen Tunneln müsse der eine die Telegramme vom anderen quittieren. Wie sieht bei dir der Aufbau genau aus?

[ChrisChros]

@killroy2 Ich habe ein IP-Interface mit mehreren Tunneln.
1x für Edomi (Logiken und Visu)
1x ioBroker
1x für die ETS

Der ioBroker sendet mit Hilfe von openKNX die Daten an die entsprechenden GAs. Die GAs sind mit einer Dummy-Applikation verbunden damit die ganzen Adressen auch importieret werden können. Alle Adressen sind wie im Screenshot des vorherigen Post parametriert.

[Markus84]

@killroy2 Hast du eigentlich irgendwo deine Paypal Adresse oder ähnliches hinterlegt, damit man dir mal eine kleine Spende zukommen lassen kann für die super Arbeit, die du hier machst?

[Tontechniker]

@killroy2 Hallo! In den "Instanzeinstellungen" bei der Version 0.5.2 kann ich nicht weit genug scrollen, um die Schaltfläche für den Import zu erreichen. Es ist maximal ein blauer Balken zu sehen. Wenn ich auf die richtige Stelle des Balkens klicke, kann ich die Datei importieren. Ist das nur bei mir so, oder ist es ein Bug?
Gruß
Hans

[ChrisChros]

@tontechniker sagte in Test Adapter OpenKNX 0.2.x:

In den "Instanzeinstellungen" bei der Version 0.5.2 kann ich nicht weit genug scrollen, um die Schaltfläche für den Import zu erreichen.

Hatte ich auch, habe dann einfach die Seite auf nur 80% Zoom gestellt, damit kann ich nun alles sehen.

[Tontechniker]

@chrischros Normalerweise müsste ich aber doch mit dem Scrollbalken (rechts) weiter nach unten kommen.
Danke für den Hinweis! Es funktioniert bei mir mit Firefox und 90% Zoom.

[ChrisChros]

@tontechniker sagte in Test Adapter OpenKNX 0.2.x:

Normalerweise müsste ich aber doch mit dem Scrollbalken (rechts) weiter nach unten kommen.

Da geb ich dir recht, aber ich glaube nicht, dass das etwas mit der Adapterprogrammierung zu tun hat. Eventuell ist das auch ein Problem des ioBrokers.

[killroy2]

Danke @Markus83 , ich baue einen Donate Button auf die Adapterseite ein, so wie es andere Projekte auch handhaben. Was mir zur Weiterentwicklung hilft ist ein KNX IP Router. Auch eine temporäre Leihgabe hilft mir schon weiter. Selber anschaffen werde ich es mir wegen fehlender Anschlussverwertung nicht.

[ChrisChros]

@killroy2
ich habe heute meinem Pi neu starten müssen. Dabei habe ich festgestellt das ich folgende Einträge im Log vorfinde:

2023-02-03 20:47:43.877  - error: openknx.0 (630) [error] 2023-02-03 19:47:43.875 (idle): Incomplete/unparseable UDP packet: Error: Invalid data for GA 3/1/14
    at fsm.event (/opt/iobroker/node_modules/iobroker.openknx/main.js:583:35)
    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:673:10)
    at fsm._onEnter (/opt/iobroker/node_modules/iobroker.openknx/lib/knx/src/FSM.js:579: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:368:16): 06100420001704a3b4002900bce01133190e03008007df
2023-02-03 20:47:43.892  - info: host.raspberrypi "system.adapter.openknx.0" disabled
2023-02-03 20:47:43.899  - info: host.raspberrypi stopInstance system.adapter.openknx.0 (force=false, process=true)
2023-02-03 20:47:43.917  - info: openknx.0 (630) Got terminate signal TERMINATE_YOURSELF
2023-02-03 20:47:43.922  - info: openknx.0 (630) terminating
2023-02-03 20:47:43.925  - info: openknx.0 (630) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2023-02-03 20:47:44.003  - info: host.raspberrypi stopInstance system.adapter.openknx.0 send kill signal
2023-02-03 20:47:44.513  - info: host.raspberrypi instance system.adapter.openknx.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2023-02-03 20:47:49.621  - info: host.raspberrypi "system.adapter.openknx.0" enabled
2023-02-03 20:47:49.866  - info: host.raspberrypi instance system.adapter.openknx.0 started with pid 2394
2023-02-03 20:47:52.196  - info: openknx.0 (2394) starting. Version 0.5.2 in /opt/iobroker/node_modules/iobroker.openknx, node: v16.19.0, js-controller: 4.0.24
2023-02-03 20:47:52.234  - info: openknx.0 (2394) Connecting to knx gateway:  10.10.20.2:3671 minimum send delay: 50ms debug level: info
2023-02-03 20:47:52.235  - info: openknx.0 (2394) /opt/iobroker/node_modules/iobroker.js-controller
2023-02-03 20:47:53.059  - info: openknx.0 (2394) Connected!
2023-02-03 20:47:53.273  - info: openknx.0 (2394) Found 939 valid KNX objects of 941 objects in adapter.

Der Adapter ist zu diesem Zeitpunkt nicht richtig gestartet und von Status gelb. Sobald ich den Adapter neu starte läuft er ohne Probleme.
Woran kann das liegen?

[killroy2]

@chrischros kannst du bitte noch die Zeilen zu openknx.0 davor posten?