NEWS
Test Adapter OpenKNX 0.6.x
-
Hallo,
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?
-
@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.
-
@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 goodFolgendes 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 - [35msilly[39m: 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 - [34mdebug[39m: 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 - [35msilly[39m: 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 - [35msilly[39m: 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 - [35msilly[39m: openknx.0 (19479) [debug] 2022-11-17 11:49:36.969 Inbound message: 0610042000150413af002900bce011011217010080
2022-11-17 12:49:36.969 - [35msilly[39m: 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 - [35msilly[39m: 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 - [35msilly[39m: openknx.0 (19479) [debug] 2022-11-17 11:49:36.970 (idle): zzzz...
2022-11-17 12:49:36.970 - [35msilly[39m: 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 - [34mdebug[39m: openknx.0 (19479) receive self ga: 1.1.1
2022-11-17 12:49:36.970 - [35msilly[39m: 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 - [35msilly[39m: openknx.0 (19479) [debug] 2022-11-17 11:49:40.829 Inbound message: 0610042000150413b0002900bce011f31118010081
2022-11-17 12:49:40.831 - [35msilly[39m: 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 - [35msilly[39m: 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 - [35msilly[39m: openknx.0 (19479) [debug] 2022-11-17 11:49:40.832 (idle): zzzz... -
@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. -
@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
-
@finkinho ok verstehe deinen Aufbau. Hold dir die Version 0.2.6 oder neuer, damit ist das Problem adressiert.
-
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
-
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
-
@killroy2 Nach Update auf 0.2.6 funktioniert's jetzt, vielen Dank!
-
@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?
-
@markus84 Die Meldung kommt beim Startup wenn zwei IOB Objekte die selbe KNX adresse eingestellt haben. Mache einen Json Export und such danach.
Bei mir habe ich sowas bisher nicht feststellen können. Kannst du das Verhalten reproduzieren und hast du Logs dazu?
-
@killroy2 Danke für den Tipp mit dem Json Export der Objekte. So ließ sich die doppelte KNX Adresse einfach finden.
Den Fehler kann ich leider nicht reproduzieren. Ich bin noch einmal runter auf die 0.2.5 und danach wieder hoch auf die 0.3.2. Es hat alles sofort funktioniert. Wenn sonst niemand das Problem hat, wird es wohl einfach bei mir irgendwo kurz gehangen haben...
In der Seitenleiste in der Administrationsoberfläche erscheint in der 0.3.2 übrigens das OpenKNX Icon und testtitle
Leider hat auch die neue Version mein Problem nicht behoben, dass zwischendurch immer mal wieder die Verbindung zu KNX verloren geht. Ich hatte das Log auf silly stehen (ich war allerdings zu Testzwecken nochmal auf die 0.2.5 zurückgegangen) und versuche gerade durchzublicken, was was genau bedeutet. Gibts dafür irgendwo eine genaue Beschreibung zum Nachlesen?
Hier scheint es irgendwie gehangen zu haben, jedenfalls gab es einen timeout.
2022-11-28 03:00:07.137 - [34mdebug[39m: openknx.0 (2879) Outbound GroupValue_Write to 0/2/16 val: false from openknx.0.Zentralfunktionen.Status.Rollos-Unten-Nacht 2022-11-28 03:00:07.163 - [35msilly[39m: openknx.0 (2879) [debug] 2022-11-28 02:00:07.163 timed out waiting for TUNNELING_ACK 2022-11-28 03:00:07.163 - [35msilly[39m: openknx.0 (2879) [debug] 2022-11-28 02:00:07.163 (idle): zzzz... 2022-11-28 03:00:07.164 - [35msilly[39m: openknx.0 (2879) [trace] 2022-11-28 02:00:07.164 (sendDatagram): Sending TUNNELING_REQUEST_L_Data.req ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":22,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":16,"tunnel_endpoint":"192.168.15.200:3671","seqnum":120},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"0.0.0","dest_addr":"0/4/27","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[0]},"bitlength":8}}} 2022-11-28 03:00:07.165 - [35msilly[39m: openknx.0 (2879) [trace] 2022-11-28 02:00:07.165 (sendDatagram): UDP sent OK: TUNNELING_REQUEST_L_Data.req 061004200016041078001100bce00000041b02008000 2022-11-28 03:00:07.165 - [35msilly[39m: openknx.0 (2879) [debug] 2022-11-28 02:00:07.165 (sendDatagram): >>>>>>> successfully sent seqnum: 7544
Sind das hier beides Schreibbefehle auf den Bus? Wenn ja, wo ist der Unterschied - also weshalb werden diese im log anders dargestellt?
2022-11-28 03:00:05.169 - [34mdebug[39m: openknx.0 (2879) Outbound GroupValue_Write to 0/1/2 val: false from openknx.0.Zentralfunktionen.Alarm.Feuer 2022-11-28 03:00:05.180 - [35msilly[39m: openknx.0 (2879) States user redis pmessage openknx.0.*/openknx.0.Zentralfunktionen.Status.Mute:{"val":false,"ack":false,"ts":1669600805120,"q":0,"c":"script.js.common.KNX.Weiterleitungen_Zu_KNX","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1669473577887}
Solche Nachrichten habe ich auch öfter im Log. Steckt da irgendetwas relevantes drin?
2022-11-28 03:00:05.163 - [35msilly[39m: openknx.0 (2879) [trace] 2022-11-28 02:00:05.163 (sendDatagram): Sending TUNNELING_REQUEST_L_Data.req ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":16,"tunnel_endpoint":"192.168.15.200:3671","seqnum":119},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"0.0.0","dest_addr":"0/2/24","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[1]},"bitlength":1}}} 2022-11-28 03:00:05.163 - [35msilly[39m: openknx.0 (2879) [trace] 2022-11-28 02:00:05.163 (sendDatagram): UDP sent OK: TUNNELING_REQUEST_L_Data.req 061004200015041077001100bce000000218010081 2022-11-28 03:00:05.163 - [35msilly[39m: openknx.0 (2879) [debug] 2022-11-28 02:00:05.163 (sendDatagram): >>>>>>> successfully sent seqnum: 7543
Oder hier?
2022-11-27 16:34:20.516 - [35msilly[39m: openknx.0 (82207) [trace] 2022-11-27 15:34:20.515 (sendDatagram): Sending TUNNELING_REQUEST_L_Data.req ==> {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":35,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunn":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":17,"tunnel_endpoint":"192.168.15.200:3671","seqnum":203},"cemi":{"msgcode":17,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"0.0.0","dest_addr":"0/4/30","apdu":{"apci":"GroupValue_Write","tpci":0,"data":{"type":"Buffer","data":[45,49,51,50,55,32,87,0,0,0,0,0,0,0]},"bitlength":112}},"disenqueue":true} 2022-11-27 16:34:20.516 - [35msilly[39m: openknx.0 (82207) [trace] 2022-11-27 15:34:20.516 (sendDatagram): UDP sent OK: TUNNELING_REQUEST_L_Data.req 0610042000230411cb001100bce00000041e0f00802d31333237205700000000000000 2022-11-27 16:34:20.516 - [35msilly[39m: openknx.0 (82207) [debug] 2022-11-27 15:34:20.516 (sendDatagram): >>>>>>> successfully sent seqnum: 3019 2022-11-27 16:34:20.517 - [35msilly[39m: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 Inbound message: 06100421000a0411cb00 2022-11-27 16:34:20.517 - [35msilly[39m: openknx.0 (82207) [trace] 2022-11-27 15:34:20.517 (sendTunnReq_waitACK): Received TUNNELING_ACK message: {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"tunnstate":{"header_length":4,"channel_id":17,"seqnum":203,"rsvd":0}} 2022-11-27 16:34:20.517 - [35msilly[39m: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 ===== datagram 203 acknowledged by IP router 2022-11-27 16:34:20.517 - [35msilly[39m: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 (idle): zzzz... 2022-11-27 16:34:20.553 - [35msilly[39m: openknx.0 (82207) [debug] 2022-11-27 15:34:20.553 Inbound message: 061004200023041140002e00bce01103041e0f00802d31333237205700000000000000 2022-11-27 16:34:20.554 - [35msilly[39m: openknx.0 (82207) [trace] 2022-11-27 15:34:20.554 (idle): Received TUNNELING_REQUEST_L_Data.con message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":35,"tunnstate":{"header_length":4,"channel_id":17,"seqnum":64,"rsvd":0},"cemi":{"msgcode":46,"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.3","dest_addr":"0/4/30","apdu":{"apdu_length":15,"apdu_raw":{"type":"Buffer","data":[0,128,45,49,51,50,55,32,87,0,0,0,0,0,0,0]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[45,49,51,50,55,32,87,0,0,0,0,0,0,0]}}}}
-
@markus84 Deine Logfiles hier sind unverdächtig.
Ich hab in deinen Logfiles gesehen dass dein Gateway das ACK nicht quittiert. Der Adapter wiederholt das dann nicht wie in der Spec gefordert. Ich hab das Verhalten mal eingebaut in Version >= 0.4.0 zusammen mit weiteren Features. Du kannst dir den aktuellen Stand auf github schon jetzt anschauen oder warten bis es rauskommt. Testen konnte noch sehr wenig... -
Eine banale Frage, aber moentan nutze ich den "normalen" KNX - Adapter. Nun würde ich gerne auf openKNX umsteigen.
Nun habe ich viele Datenpunkte (Objekte) die in eine InfluxDB geschrieben werden. Zudem werden viele Datenpunkte in Script´s verwendet, in der VIS, im iqontrol-Adapter verwendet.Gibt es eine "Deutsche" Anleitung, wie man das am besten auf einen Schwung umstellen kann? Denn einzeln alles auf openKNX "umzuklicken" und zudem 2 KNX Adapter laufen zu lassen, wäre eine Katastrophe.
-
@killroy2 Nochmal danke fürs Drüberschauen. Mit einem frame delay von 200 ms lief es zuletzt mehrere Tage stabil - wenn auch langsam.
Die Version 0.4.0 habe ich versucht zu testen. Leider gibt es einen restart loop und der Adapter bleibt rot:
openknx.0 2022-12-16 21:58:00.969 silly States system redis pmessage system.adapter.openknx.0.logLevel/system.adapter.openknx.0.logLevel:{"val":"silly","ack":true,"ts":1671224280966,"q":0,"from":"system.adapter.openknx.0","lc":1669449235187} openknx.0 2022-12-16 21:58:00.967 warn Terminated (UNCAUGHT_EXCEPTION): Without reason openknx.0 2022-12-16 21:58:00.966 debug Plugin sentry destroyed openknx.0 2022-12-16 21:58:00.966 info terminating openknx.0 2022-12-16 21:58:00.962 error Cannot read properties of undefined (reading 'init') openknx.0 2022-12-16 21:58:00.962 error TypeError: Cannot read properties of undefined (reading 'init') at openknx.onReady (/opt/iobroker/node_modules/iobroker.openknx/main.js:82:33) at openknx.emit (node:events:513:28) at openknx.emit (node:domain:489:12) at /opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.js:9132:26 openknx.0 2022-12-16 21:58:00.917 error unhandled promise rejection: Cannot read properties of undefined (reading 'init') openknx.0 2022-12-16 21:58:00.917 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). openknx.0 2022-12-16 21:58:00.908 info starting. Version 0.4.0 (non-npm: iobroker-community-adapters/ioBroker.openknx) in /opt/iobroker/node_modules/iobroker.openknx, node: v16.18.1, js-controller: 4.0.23 openknx.0 2022-12-16 21:58:00.782 debug Plugin sentry Initialize Plugin (enabled=true) openknx.0 2022-12-16 21:57:29.786 silly States system redis pmessage system.adapter.openknx.0.logLevel/system.adapter.openknx.0.logLevel:{"val":"silly","ack":true,"ts":1671224249766,"q":0,"from":"system.adapter.openknx.0","lc":1669449235187} openknx.0 2022-12-16 21:57:29.769 warn Terminated (UNCAUGHT_EXCEPTION): Without reason openknx.0 2022-12-16 21:57:29.769 debug Plugin sentry destroyed openknx.0 2022-12-16 21:57:29.768 info terminating openknx.0 2022-12-16 21:57:29.761 error Cannot read properties of undefined (reading 'init') openknx.0 2022-12-16 21:57:29.761 error TypeError: Cannot read properties of undefined (reading 'init') at openknx.onReady (/opt/iobroker/node_modules/iobroker.openknx/main.js:82:33) at openknx.emit (node:events:513:28) at openknx.emit (node:domain:489:12) at /opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.js:9132:26 openknx.0 2022-12-16 21:57:29.716 error unhandled promise rejection: Cannot read properties of undefined (reading 'init') openknx.0 2022-12-16 21:57:29.716 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). openknx.0 2022-12-16 21:57:29.707 info starting. Version 0.4.0 (non-npm: iobroker-community-adapters/ioBroker.openknx) in /opt/iobroker/node_modules/iobroker.openknx, node: v16.18.1, js-controller: 4.0.23 openknx.0 2022-12-16 21:57:29.597 debug Plugin sentry Initialize Plugin (enabled=true) openknx.0 2022-12-16 21:57:29.546 silly statesDB connected openknx.0 2022-12-16 21:57:29.545 debug States connected to redis: 127.0.0.1:9000 openknx.0 2022-12-16 21:57:29.489 debug States create User PubSub Client openknx.0 2022-12-16 21:57:29.489 debug States create System PubSub Client openknx.0 2022-12-16 21:57:29.482 debug Redis States: Use Redis connection: 127.0.0.1:9000 openknx.0 2022-12-16 21:57:29.482 silly objectDB connected openknx.0 2022-12-16 21:57:29.480 silly redis psubscribe cfg.o.enum.* openknx.0 2022-12-16 21:57:29.472 silly redis psubscribe cfg.o.system.user.* openknx.0 2022-12-16 21:57:29.471 debug Objects connected to redis: 127.0.0.1:9001 openknx.0 2022-12-16 21:57:29.470 debug Objects client initialize lua scripts openknx.0 2022-12-16 21:57:29.449 debug Objects create User PubSub Client openknx.0 2022-12-16 21:57:29.448 debug Objects create System PubSub Client openknx.0 2022-12-16 21:57:29.448 debug Objects client ready ... initialize now openknx.0 2022-12-16 21:57:29.434 debug Redis Objects: Use Redis connection: 127.0.0.1:9001
-
Ich finde den Adapter auch toll und rennt soweit. Was mich verwundert hat, überall sehe ich, u d so kenne ich es eigentlich auch, muss die Physical KNX adress angegeben werden. Bei mir wird aber dieset Punkt nicht angezeigt. Hatte mehrere Versionen versucht aber bei keiner kam hier eine Eingabemöglichkeit.
-
@killroy2 habe heute das update von 0.3.2 auf 0.4.0 durchgeführt. Leider startet danach der Adapter nicht mehr. Hier mal der debug log, ich hoffe das es hilfreich ist.
2022-12-17 17:14:12.014 - info: host.raspberrypi "system.adapter.openknx.0" enabled 2022-12-17 17:14:12.257 - info: host.raspberrypi instance system.adapter.openknx.0 started with pid 10351 2022-12-17 17:14:13.881 - debug: openknx.0 (10351) Redis Objects: Use Redis connection: 127.0.0.1:9001 2022-12-17 17:14:13.923 - debug: openknx.0 (10351) Objects client ready ... initialize now 2022-12-17 17:14:13.926 - debug: openknx.0 (10351) Objects create System PubSub Client 2022-12-17 17:14:13.928 - debug: openknx.0 (10351) Objects create User PubSub Client 2022-12-17 17:14:13.964 - debug: openknx.0 (10351) Objects client initialize lua scripts 2022-12-17 17:14:13.972 - debug: openknx.0 (10351) Objects connected to redis: 127.0.0.1:9001 2022-12-17 17:14:14.000 - debug: openknx.0 (10351) Redis States: Use Redis connection: 127.0.0.1:9000 2022-12-17 17:14:14.013 - debug: openknx.0 (10351) States create System PubSub Client 2022-12-17 17:14:14.015 - debug: openknx.0 (10351) States create User PubSub Client 2022-12-17 17:14:14.035 - debug: openknx.0 (10351) States connected to redis: 127.0.0.1:9000 2022-12-17 17:14:14.124 - debug: openknx.0 (10351) Plugin sentry Initialize Plugin (enabled=true) 2022-12-17 17:14:14.533 - info: openknx.0 (10351) starting. Version 0.4.0 in /opt/iobroker/node_modules/iobroker.openknx, node: v16.18.1, js-controller: 4.0.24 2022-12-17 17:14:14.571 - error: openknx.0 (10351) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). 2022-12-17 17:14:14.572 - error: openknx.0 (10351) unhandled promise rejection: Cannot read properties of undefined (reading 'init') 2022-12-17 17:14:14.797 - error: openknx.0 (10351) TypeError: Cannot read properties of undefined (reading 'init') at openknx.onReady (/opt/iobroker/node_modules/iobroker.openknx/main.js:82:33) at openknx.emit (node:events:513:28) at openknx.emit (node:domain:489:12) at /opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.js:9139:26 2022-12-17 17:14:14.798 - error: openknx.0 (10351) Cannot read properties of undefined (reading 'init') 2022-12-17 17:14:14.821 - info: openknx.0 (10351) terminating 2022-12-17 17:14:14.823 - debug: openknx.0 (10351) Plugin sentry destroyed 2022-12-17 17:14:14.824 - warn: openknx.0 (10351) Terminated (UNCAUGHT_EXCEPTION): Without reason 2022-12-17 17:14:15.412 - error: host.raspberrypi Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: 2022-12-17 17:14:15.412 - error: host.raspberrypi Caught by controller[1]: TypeError: Cannot read properties of undefined (reading 'init') 2022-12-17 17:14:15.412 - error: host.raspberrypi Caught by controller[1]: at openknx.onReady (/opt/iobroker/node_modules/iobroker.openknx/main.js:82:33) 2022-12-17 17:14:15.413 - error: host.raspberrypi Caught by controller[1]: at openknx.emit (node:events:513:28) 2022-12-17 17:14:15.413 - error: host.raspberrypi Caught by controller[1]: at openknx.emit (node:domain:489:12) 2022-12-17 17:14:15.413 - error: host.raspberrypi Caught by controller[1]: at /opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.js:9139:26 2022-12-17 17:14:15.414 - error: host.raspberrypi instance system.adapter.openknx.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 2022-12-17 17:14:15.414 - info: host.raspberrypi Restart adapter system.adapter.openknx.0 because enabled 2022-12-17 17:14:39.593 - info: host.raspberrypi "system.adapter.openknx.0" disabled 2022-12-17 17:14:47.151 - debug: openknx.0 (10366) Redis Objects: Use Redis connection: 127.0.0.1:9001 2022-12-17 17:14:47.194 - debug: openknx.0 (10366) Objects client ready ... initialize now 2022-12-17 17:14:47.197 - debug: openknx.0 (10366) Objects create System PubSub Client 2022-12-17 17:14:47.198 - debug: openknx.0 (10366) Objects create User PubSub Client 2022-12-17 17:14:47.267 - debug: openknx.0 (10366) Objects client initialize lua scripts 2022-12-17 17:14:47.297 - debug: openknx.0 (10366) Objects connected to redis: 127.0.0.1:9001 2022-12-17 17:14:47.327 - debug: openknx.0 (10366) Redis States: Use Redis connection: 127.0.0.1:9000 2022-12-17 17:14:47.340 - debug: openknx.0 (10366) States create System PubSub Client 2022-12-17 17:14:47.342 - debug: openknx.0 (10366) States create User PubSub Client 2022-12-17 17:14:47.361 - debug: openknx.0 (10366) States connected to redis: 127.0.0.1:9000 2022-12-17 17:14:47.452 - debug: openknx.0 (10366) Plugin sentry Initialize Plugin (enabled=true) 2022-12-17 17:14:47.676 - error: openknx.0 (10366) adapter disabled 2022-12-17 17:14:47.687 - debug: openknx.0 (10366) Plugin sentry destroyed 2022-12-17 17:14:47.689 - warn: openknx.0 (10366) Terminated (NO_ADAPTER_CONFIG_FOUND): Without reason 2022-12-17 17:14:48.278 - error: host.raspberrypi instance system.adapter.openknx.0 terminated with code 3 (NO_ADAPTER_CONFIG_FOUND) 2022-12-17 17:14:48.279 - info: host.raspberrypi Do not restart adapter system.adapter.openknx.0 because disabled or deleted
Habe nun wieder die Version 0.3.2 installiert, damit ist alles bestens.
Gruß Chris
-
@quorle mit etwas Basteln sollte mit vertretbaren Aufwand gehen:
die bestehenden Tabellen ausgeben lassen und damit eine Liste erstellen die dann alle Tabellen kopiert- login via SSH to your IOBroker and run command influx
- use iobroker (or your specific database listed via command show databases)
- list entries with: show measurements
- copy tables with command: select * into "entry_new" from "entry_old";
where entry_new points to the old adapter object path and entry_new the openknx adapter instance
Und dann den openknx IOB Objektbaum exportieren und mit einem Editor überall setzen:
- set influx enabled for new object entry_new
-
@chrischros @markus84 danke, ich hab jetzt eine 0.4.1 gebaut
-
@killroy2 Danke, Adapter startet nun und läuft soweit.