Der KNX Adapter wird in der neuen Version auch für Privatanwender (abgesehen von sehr kleinen Installationen) kostenpflichtig. Für mich würde dies ca. 26 € im Jahr oder 262 € einmalig (für die konkrete Version) bedeuten. Das ist alles schon irgendwie verschmerzbar, aber wenn erst einmal so etwas akzeptiert wird, ist meine Befürchtung, dass andere Adapter auch kostenpflichtig werden. Und dann kann es bei 10-15 Adaptern natürlich teuer werden...

Im KNX Thread wurde dies diskutiert, gehört aber nicht wirklich dorthin (obwohl es bisher im Grundsatz nur diesen Adapter betrifft). Auch scheinen sich nur wenige daran zu stören. Ich sehe dies jedoch als großes Problem für iobroker, sofern dies kein Einzelfall bleiben wird. Denn die Attraktivität von iobroker im Vergleich zu anderen System würde massiv sinken, wenn nicht nur völlig zu vernachlässigende Kosten anfallen.

Daher meine Frage an die Core-Entwickler (oder wer auch immer hierfür verantwortlich ist): Darf jeder Entwickler für seinen Adapter verlangen was er will? Gibt es diesbezüglich irgendwelche Vorgaben bzw. beabsichtigt ihr welche?

Sehe nur ich hier ein größeres und generelles Problem?

@Jey-Cee Also ich finde deinen Adapter super und er funktioniert bei mir auch einwandfrei. Für mich wäre Möglichkeit 3 daher eine Katastrophe. Gerade die Verbesserungen in Version 2 finde ich top.

Auch wenn hier nicht jeder mitliest und sich meldet geht es glaube ich vielen Leuten so wie mir.

Zu Möglichkeit 1 und 2 habe ich keine Meinung. Ich bin aber gerne bereit beim Testen zu unterstützen - egal für welchen Weg du dich entscheidest.

Dieser Beitrag wurde am 03.01.2022 vom Ersteller gelöscht und am 04.1.2022 vom ioBroker-Team wiederhergestellt um den Zusammenhang des Threads zu gewährleisten

@apollon77 ich denke auch, dass die Attraktivität von iobroker mit jedem kostenpflichtigen Adapter sinkt. Wer vor der Entscheidung steht sich ein System auszusuchen wird die Kosten klar berücksichtigen.

Klar, gar keinen Adapter für etwas zu haben, steigert die Attraktivität natürlich auch nicht.

Aber spinnt das ganze doch mal weiter. Mit nur 10 Adaptern pro Jahr zu 15€ kostet es schon 150€ im Jahr. Und ich bin mir sicher der ein oder andere Entwickler wird sich denken: „Warum soll ich mir die Arbeit kostenlos machen, wenn andere damit Geld verdienen?“

Und wenn man den Preis dieses Adapters auf iobroker an sich überträgt, wären 50-100 € hierfür keinesfalls zu viel.

Alleine eine Diskussion wie diese ist das schlechteste was passieren kann hinsichtlich unentschlossenen Nutzern, die nach einen System suchen.

Ich finde iobroker super und habe mir auch sofort die vis offline Lizenz gekauft. Nicht weil ich es bräuchte, aber um zu unterstützen. Und das ohne jeglichen Zwang.

Vielleicht sehe ich es zu pessimistisch, aber sollten noch mehr Adapter kostenpflichtig werden, dürfte das mittelfristig das Ende von iobroker bedeuten. Dafür ist die kostenlose Konkurrenz auf dem Markt einfach zu groß. Und das ist wohl etwas was keiner hier möchte.

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

Was spricht denn aus Deiner Sicht dagegen?

Juristisch und wirtschaftlich: Gar nichts, da gebe ich dir völlig recht. Wir leben aber in einer Gesellschaft, in der manch einem 0,99 € für eine Handyapp zu viel sind und sie lieber stundenlang mit irgendwelchen workarounds versuchen den einen Euro zu sparen. Ich mache mir aktuell überhaupt keine Sorgen. Die 26 € für den KNX Adapter pro Jahr kann ich mir leisten. Und natürlich ist es gerade noch nicht einmal 1% aller Adapter. Aber was wenn es 10% sind? Meinst du nicht, dass dann doch viele ausweichen auf ein anderes System und ioBroker dadurch nachhaltig geschwächt wird?

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

Hier wird so getan, als ob man plötzlich 30€ pro Monat zahlen müsste, um den ioBroker überhaupt noch zu verwenden. Da ist absolut kein Trend zu erkennen.

Lass uns mal ein Jahr abwarten. Ich lasse mich gerne eines besseren belehren, wenn es bis dahin immer noch kaum kostenpflichtige Adapter gibt. Ich arbeite den ganzen Tag mit Menschen. Nichts ist schlimmer als dass der Kollege etwas bekommt, was man selbst nicht bekommt... Ich kann mir daher sehr gut vorstellen, dass sich das ändern wird.

Und wenn du nur 10 kostenpflichtige Adapter bräuchtest (ausgehend vom Preis des KNX Adapters), dann wärest du von den 30 € im Monat nicht mehr so weit entfernt...

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

Komischerweise stößt niemand eine Diskussion an, ob die vielen tausend Stunden Entwicklung des Core-Teams nicht honoriert werden sollten.

Das hatte ich in dem anderen Thread bereits erwähnt. Ist es nicht unfair, dass die Core-Entwickler nichts (oder nur einen vermutlich kleinen Prozentsatz Beteiligung an den Adapterverkäufen) bekommen, ein Adapterentwickler aber Geld damit verdient? Wenn man sich für 2 € im Monat irgendein nicht zwingend erforderliches Premiumfeature kaufen kann (ein anderes Hintergrundbild im Admin oder sonst irgendetwas wie die VIS offline Version) würden glaube ich viele sofort zuschlagen und ioBroker an sich gerne unterstützen. Aber 26 € im Jahr für einen einzelnen Adapter und den 10-fachen Betrag für eine nicht näher definierte Lifetime-Lizenz? Da passt (meine Meinung!) einfach etwas nicht ganz zusammen.

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

OT: Nimm doch mal WordPress, Shopware, Magento, Typo3, oder irgendeine andere Lösung. Für alle diese Projekte gibt es kostenpflichtige Module/Extensions von Dritten.

Naja, das ist jetzt wie Äpfel mit Birnen zu vergleichen. Auch für Linux gibt es kostenpflichtige Programme, obwohl es an sich OpenSource ist. Die von dir genannte Software hat jeweils eine weltweite Verbreitung und wenn mal 50.000 Nutzer sich ein anderes System suchen, dann fällt das nicht ins Gewicht. Das sieht bei ioBroker doch anders aus...

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

... am besten allen erstmal erklären, wieviel € sie für ihre Dienstleistung so nehmen dürfen?

Ich wähle nicht die Linken und bin auch ein Kommunist. Jeder darf für seine Dienstleistung nehmen was er möchte bzw. so viel wie andere bereit sind dafür zu zahlen. Den Rest regelt der Markt. Soweit bin ich komplett deiner Meinung. Aber anscheinend bin ich einer der wenigen, die hier generell Bedenken haben, wie sich kostenpflichtige Adapter auf ioBroker auswirken...

Hallo liebe Entwickler,

ich finde ioBroker super und würde mich gerne etwas über die weitere Entwicklung informieren.

Auf github steht im changelog und auch unter projects beim js-controller, dass die Version 3.2 für September geplant war. Habt ihr hier größere Probleme? Zumindest mit der Version 3.1.7 und 3.1.8 gab es ja Probleme.

Generell fände ich es super, dass wenn ihr kurz (mir ist klar, dass auch so etwas Zeit kostet) und auch "laienverständlich" euch ab und an mal melden könntet und sagt woran ihr gerade arbeitet. Die Anmerkungen bei der jeweiligen Agenda der Entwicklertreffen verstehe zumindest ich überhaupt nicht. Auch die einzelnen Punkte unter projects (done, in progress, planned) verstehe ich größtenteils nicht.

Mir ist durchaus bewusst, dass ihr alle Hände voll mit der Entwicklung zu tun habt, aber wenn ihr ab und an mal mitteilen könntet wie es mit ioBroker weitergeht (oder auch wo es gerade hakt) fände ich das super.

Viele Grüße und danke für eure super Arbeit!

@ssw-mcor said in Kostenpflichtige iobroker Adapter:

Alter vergiss es, mit dir kann man einfach nicht normal reden

Die Umgangsform geht gar nicht!

@ssw-mcor said in Kostenpflichtige iobroker Adapter:

Dann sind wir ja einer Meinung, dass ioBroker damit nichts zu tun hat und das Thema heir nicht hingehört

Nein !!!

Das Thema gehört wirklich nicht hier hin. Klärt das doch bitte an entsprechender Stelle, falls noch Bedarf besteht.

@haus-automatisierung said in Kostenpflichtige iobroker Adapter:

Und Du glaubst nicht, dass dann hier im Forum neue Threads mit der "Angst der Kommerzialisierung von ioBroker" eröffnet werden? Und dann manche User den Trend erkennen werden, dass bald ALLES kostenpflichtig wird? Das wäre ja bestimmt nur der erste Schritt... oder?

Zugegeben ich musste schon schmunzeln als ich das gelesen habe

Aber ernsthaft, wenn sich das etablieren sollte, gibt es kein (oder nur ein sehr schweres) zurück mehr (falls das irgendwann mal gewollt sein sollte). Deshalb ist mein Vorschlag sowas direkt anzusprechen (so schwierig und unangenehm das auch sein mag)... Wer dann welche Entscheidung tritt, darauf habe ich ohnehin keinen Einfluss.

@UncleSam Ein Punkt ist mir doch noch eingefallen, der mir fehlt: Failover. Wenn mein Server ausfällt ist erst einmal alles offline. Und das käme zu Hause nicht wirklich gut an. Eine Möglichkeit, dass ein zweiter, immer synchron gehaltener Server sofort übernehmen könnte wäre für den Fall der Fälle echt hilfreich.

@Bostil said in Rolladenmotor an Shelly (Frage zu Setup):

Hoffe, dass ich mit einem Fritzbox-Mesh klarkomme, um ausreichend WLAN zur Verfügung zu stellen.

Ich habe mir bereits in unserer jetzigen Wohnung Unifi Geräte bestellt und teste sie seit 3 Monaten. Vielleicht kommt das für dich ja auch in Frage. Gerade die Accesspoints kann man über PoE betreiben (und braucht daher unter der Decke nicht noch zusätzlich Strom) und die Verbindungen sind (zumindest bei mir) wesentlich stabiler geworden seitdem ich von Fritzbox auf Unifi umgestiegen bin. Auch wollte ich eine weitere Sicherheitsschicht einbauen, indem ich den ganzen IOT Kram vom Rest meines Netzwerks trenne.

@apollon77 Danke für die Erklärung. Hab etwas gebraucht, um durch das System durchzublicken. Ist dann aber durchaus logisch aufgebaut.

@paul53 Hat bestens funktioniert, vielen Dank!

@paul53 Besten Dank, ich probiere es später aus!

@paul53 Danke, es ist schon spät, ich habe meine Frage total blöd gestellt. Ich meinte eigentlich etwas ganz anderes, was man anhand der Fragestellung allerdings nicht verstehen konnte. Ich will an diesen Wert des Datenpunktes dran und ihn ändern:

@paul53 Hi, danke für die schnelle Antwort. Ich brauche keinen Auslöser. Es soll nur einmalig durchlaufen und den Wert ändern. Kann man also von Hand anstoßen.

Hallo,
ich habe einen Ordner mit einer Vielzahl von Datenpunkten. Alle Datenpunkte in diesem Ordner haben den Wert "xy": true, welchen ich gerne auf false ändern möchte ohne dabei jeden Datenpunkt einzeln bearbeiten zu müssen. Gibt es hierfür eine Möglichkeit?
Danke für eure Hilfe
Markus

@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?

@killroy2 Macht es vielleicht Sinn, da der Adapter nahezu fehlerfrei funktioniert, den Adapter offiziell zu Version 1 zu machen? Wird damit für "Neulinge" deutlicher, dass es sich hierbei nicht mehr um ein Alpha- bzw. Betastadium handelt?

@killroy2 said in Test Adapter OpenKNX 0.2.x:

@chrischros @markus84 danke, ich hab jetzt eine 0.4.1 gebaut

Läuft auch bei mir bis jetzt fehlerfrei

@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

@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  - debug: 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  - silly: openknx.0 (2879) [debug] 2022-11-28 02:00:07.163 timed out waiting for TUNNELING_ACK
2022-11-28 03:00:07.163  - silly: openknx.0 (2879) [debug] 2022-11-28 02:00:07.163 (idle):	 zzzz...
2022-11-28 03:00:07.164  - silly: 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  - silly: 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  - silly: 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  - debug: 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  - silly: 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  - silly: 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  - silly: 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  - silly: 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  - silly: 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  - silly: 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  - silly: openknx.0 (82207) [debug] 2022-11-27 15:34:20.516 (sendDatagram):	>>>>>>> successfully sent seqnum: 3019
2022-11-27 16:34:20.517  - silly: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 Inbound message: 06100421000a0411cb00
2022-11-27 16:34:20.517  - silly: 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  - silly: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 ===== datagram 203 acknowledged by IP router
2022-11-27 16:34:20.517  - silly: openknx.0 (82207) [debug] 2022-11-27 15:34:20.517 (idle):	 zzzz...
2022-11-27 16:34:20.553  - silly: openknx.0 (82207) [debug] 2022-11-27 15:34:20.553 Inbound message: 061004200023041140002e00bce01103041e0f00802d31333237205700000000000000
2022-11-27 16:34:20.554  - silly: 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]}}}}