Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[killroy2]

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

[dachauan]

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

[netfriend]

@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.202

BC 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.

[dachauan]

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.

[netfriend]

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

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

@dachauan Super, probier ich gerne aus. Wo ist das drin, wie komme ich dazu?

[dachauan]

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

[netfriend]

@dachauan Alles klar, Installation hat geklappt, danke Dir - wieder was gelernt.
Der erste Versuch hat schon mal geklappt, der Aktor schaltet. :+1: Danke für Deine Bemühungen!
Werde später noch weiter testen...

[andreaskos]

Hi zusammen,

ich hab mittlerweile schon viele Anlagen mit ioBroker und KNX in Betrieb genommen und muss sagen:
Herzliche Gratulation @killroy2 !
Ich hab hier schon eine Weile mitgelesen und seit letzter Woche den Adapter erstmals im Test. Das Ergebnis ist sehr erfreulich. Das Importieren geht zügig und die Kommunikation läuft problemlos. Seit dem ersten Einschalten des Adapters. :-)

Ich verwende übrigens (meistens, aber nicht immer) den IP-Router von INTERRA: https://www.smarthomekos.at/shop/interra/systemgeräte/#cc-m-product-16999766496

Ich hab zwar eigene Scripte, die die Action- und Status-Datenpunkte zusammenführen zu einem Kombi-Datenpunkt, aber grundsätzlich finde ich die Lösung mit den Aliases sehr elegant!

Liebe Grüße
Andreas

[killroy2]

@netfriend said in Test Adapter OpenKNX 0.1.x:

Vermutlich setzen Sie dieses Bit (acknowledge request) fälschlicherweise irgenwo in Ihrem RaspberryPi4
mit IoBroker und dem openKNX-Adapter.

Ich verstehe nicht auf welche Anforderung der Weinzierl Support mit dieser Aussage abziehlt.
Laut Spec gibt es keinen unterschied ob das ACK Flag gesetzt ist oder nicht.

https://github.com/Supergiovane/node-red-contrib-knx-ultimate/issues/78 erweckt den Eindruck, dass manche Empfänger das Telegramm deswegen verwerfen, warum auch immer.
Hersteller scheinen das Verhalten zu kennen und aktiv herauszufiltern. Mein MDT und Weinzierl 730 machen das.

Ich werde jetzt den Adapter einfach so umbauen, dass er immer mit ACK = 0 sendet. Ich sehe keine Notwendigkeit eine 1 schicken zu können.

[netfriend]

@killroy2 Irgendwie ist es schon komisch. Der Weinzierl Support schreibt ja selber dass das (alte) 730 das prüft und ggf. ersetzt, das neuere 732 macht das aber nicht.
Ich hatte auch gestern nochmal nachgefragt, ob es zwischenzeitlich ein Firmwareupdate für das 732 gibt, wo dieses Verhalten behoben ist. War ja in dem oben verlinkten Beitrag so angedeutet. Klare Antwort: nein, gibt es nicht.
Ich empfinde das eigentlich als Verschlimmbesserung.
Umso mehr freue ich mich, dass es in openknx angepasst wurde und es nun funktioniert!

[killroy2]

0.1.21 ist jetzt herausen

Changelog

0.1.21 (2022-02-25)

• feature: dont sent ack request in ldata.ind, this is disturbing clients if not filtered out by gateway
• bugfix: reinit if event received before connection established to avoid deadlock
• dependency:adapter core must be 2.6.0 or higher

[ChrisChros]

@killroy2
Hast du irgendetwas am logging bei der neuen Version geändert?
Aktuell bekomme ich mit der neuen Version viele Meldungen über falsche Datentypen:

2022-02-26 09:22:48.798 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Strom_Lambdasonde" has to be type "number" but received type "string"
2022-02-26 09:22:48.899 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Anforderung_HK_Regler_1" has to be type "number" but received type "string"
2022-02-26 09:22:48.982 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Anforderung_HK_Regler_2" has to be type "number" but received type "string"
2022-02-26 09:22:49.285 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Spreizung_Rücklauf" has to be type "number" but received type "string"
2022-02-26 09:22:49.867 - info: openknx.0 (14002) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Pumpe_HK1" has to be type "boolean" but received type "string"
2022-02-26 09:18:01.486 - info: openknx.0 (13974) State value to set for "openknx.0.Zentral.Wetter___Zeit___Datum.Luftfeuchte" has to be type "number" but received type "string"

Diese Meldungen hatte ich mit den alten Versionen nicht erhalten.

Zusätzlich bekomme ich seit dem Adapter-Update auch noch Log-Einträge von dem InfluxDB-Adapter der bestimmte KNX-Datenpunkte aufzeichnen soll

2022-02-26 09:18:02.496 - warn: influxdb.0 (10853) Error on writePoint("{"value":"null","time":"2022-02-26T08:18:01.488Z","from":"system.adapter.openknx.0","q":0,"ack":true}): Error: {"error":"partial write: field type conflict: input field \"value\" on measurement \"openknx.0.Zentral.Wetter___Zeit___Datum.Luftfeuchte\" is type string, already exists as type float dropped=1"}

Wie kann ich die alte Version 0.1.20 wiederherstellen?

cd /opt/iobroker
npm install iobroker.openknx@0.1.20 --production

damit sollte es doch klappen oder?

[killroy2]

@chrischros sorry, da war ein grober Fehler drin, nimm die 0.1.22; muss meine Tests anpassen sowas besser zu erkennen

[ChrisChros]

@killroy2
Danke für das schnelle Update, sieht bisher sehr gut aus.

Rein aus Interesse, worin bestand der Fehler in der vorherigen Version?

[netfriend]

@killroy2 Hat sich denn in der 0.1.22 etwas geändert bzgl. DPT? Also z.B. das Thema mit dem DPT 12.1200, ist das inzwischen enthalten oder kommt das später?

[beetlejules]

Moin zusammen,

Danke erst mal für den Adapter, funktioniert bestens soweit.
Steige gerade vom anderen "alten" Adapter um und jetzt ist mir aber noch ein Problemchen mit dem DPT 3 aufgefallen. Es liegt vermutlich nicht am Adapter, eher am Datentyp oder sonst ein Verständnisproblem meinerseits.

Ich steuere eine HUE Leuchte mit dem KNX Schalter aktuell wie folgt und es funktioniert

// Dimmen
// 1,1=dimUp, 0=stop, 0,1=dimDown
on({id: 'knx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ', change: "ne"}, async function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  // Dimmen hoch
  if (getState("0_userdata.0.dimUp").val == getState("knx.0.Dimmaktoren.Helligkeit_relativ.Küche_Deckenleuchte_Helligkeit_relativ").val) {
    setState("hue-extended.0.lights.005-küche_deckenleuchte.action._commands"/*Küche Deckenleuchte - Apply multiple commands on the device*/, ('' + (['{"bri_inc":254,"transitiontime":10,"ct":',getState("0_userdata.0.FarbtemperaturSoll").val,'}'].join(''))));
  }

Passe ich alles auf OpenKNX an, scheitert es am Vergleich der Userdata Variable mit der KNX Variable.
Userdata Variable ist natürlich angepasst.

Alt:
KNX

Userdata

Neu:
KNX

Userdata

Hat jemand eine Idee?
Vielen Dank

[killroy2]

@beetlejules said in Test Adapter OpenKNX 0.1.x:

DPT 3
unittest ist läuft durch mit 0.1.22 und ich habs im life system positiv getestet:
{"decr_incr":1,"data":2}
Welche Fehlermeldung bekommst du in der Console?
Welche Version vom Adapter?

[killroy2]

@netfriend ja ist drin