Test Adapter OpenKNX 0.6.x

[quorle]

@lessthanmore Also wenn ich die z.B. die Nummer 50 vom ioB auf den Bus sende kommt folgendes (siehe Bild)

Schalte ich vom Bus aus die Szene 50, steht folgendes im iob-Objekt:

{"save_recall":"0","scenenumber":50}

Beim knx.0 Adapter musste man lediglich eine Zahl schicken.

Edit:
Gerade heraus gefunden, wenn man

{"save_recall":"0","scenenumber":51}

vom IOB zum Bus schickt, bekommt man die Szene geschaltet.

Heißt ich muss meine Szenenprogramme alle umschreiben

[killroy2]

Ich habe jetzt Version 0.4 herausgebracht. Die Änderungen sind:

• feature: support for Free and Two Level Group Address Style in addition to the existing Three Level support #320
• feature: map knx datapoint type enconding to object common.states #313
  Dh man kann jetzt die Enums, die KNX definiert, direkt im IOB nutzen.
  
  Werte stehen im Objekt selber:
  "states": {
  "0": "Up",
  "1": "Down"
  }

[ChrisChros]

@killroy2 seit ich die Version 0.4.4 verwende bekomme ich im Log sehr viele Einträge mit folgendem oder ähnlichem Wortlaut:

2022-12-23 07:15:15.657  - info: openknx.0 (3559) State value to set for "openknx.0.Schalten.Schalten.EG_-_Gäste_WC_-_Licht_-_Schalten" has to be type "boolean" but received type "number" 
2022-12-23 07:15:15.798  - info: openknx.0 (3559) State value to set for "openknx.0.Schalten.Status_Schalten.EG_-_Gäste_WC_-_Licht_-_Status_Schalten" has to be type "boolean" but received type "number" 
2022-12-23 07:15:16.791  - info: openknx.0 (3559) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Pumpe_HK1" has to be type "boolean" but received type "number" 
2022-12-23 07:15:16.863  - info: openknx.0 (3559) State value to set for "openknx.0.Heizung.Hargassner_Nano_PK.Mischer_Auf_HK1" has to be type "boolean" but received type "number" 

Hängt das eventuell mit dem neuen Feature Enums zusammen? Mit der vorherigen Version 0.3.2 hatte ich diesbezüglich nicht solche Meldungen im Log.

Gruß Chris

[Markus84]

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

[quorle]

@ChrisChros
Habe das selbe Problem. Zudem sind alle Logikwerte nun als "Zahl" im State deklariert. Händisch müsste man sämtlichen Objekte für "Logikwerte" von Zahl auf Logikwert umstellen.
Müsste gefixt werden, da kein Script damit klar kommt.

[killroy2]

@chrischros
Ja richtig, die Spec denfiniert einen der vielen B1 Typen als DPT_Bool. Ich werde in der nächsten Version eine Einstellung anbieten wo jeder selber 1 Bit Datentypen als boolean einstellen kann.

[killroy2]

Neues Update auf Version 0.5 ist jetzt heraußen.
-Neue Datentypen sind jetzt per default auf bool gestellt, per Einstellung im Import kann es als enum number angeleget werden.
-Beim Autoread nach Neustart hatte ich unterwünscht ausgelöste Aktionen. Das lag einerseits an der ETS Konfiguration wo Trigger-Signale ein KO mit R Flag hatten.
Der Adapter hat andererseits ACK Flags generiert, wo keine sein sollten. Das habe ich mit dem Update korrigiert.

[ChrisChros]

@killroy2 Danke für das Update.
Ich bekomme folgende Meldungen nun im Log angezeigt:

GroupValue_Write confirmation false received for 4/5/6 ....

was hat es damit auf sich?

[Tontechniker]

@killroy2 Hallo! Habe gestern Vormittag die 0.5.0 installiert. In meiner Anlage läuft alles soweit!
Vielen Dank für Deine Arbeit!
Ich wünsche Dir und allen, die hier mitlesen ein gesundes, produktives und erfolgreiches Jahr 2023!
Hans

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