Installation der Testversion
"Adapter", "Expertenmodus", "Octocat", "Benutzerdefiniert" und diesen Link:
https://github.com/iobroker-community-adapters/ioBroker.openknx.git

Adapter Beschreibung, Changelog etc.
Hier ist die erste öffentliche Testversion des Open KNX Adapters. Der Adapter kommuniziert über ein IP Interface mit dem KNX Bus. Verschiedene KNX Telegrammtypen (GroupValue_Read, GroupValue_Write, GroupValue_Response) in Sende- und Empfangsrichtung werden in, dem IOB Anwender vertrauten Interaktionen mit IoBroker Objekten übersetzt.

Motivation
Ich habe den Adapter aus einer Not heraus erstellt, da der verfügbare Adapter nicht fehlerfrei lief und nicht kompatibel zu meinen IP Interfaces ist. Debuggen war aufgrund Closed Source nicht möglich. Da Adapter läuft so gut, dass ich ihn der Öffentlichkeit übergeben möchte.
Der Adapter ist Quelloffen, Code kann gerne von Jedermann inspiziert und Pull Requests eingestellt werden.
Eine Beschreibung des Adapters und dessen Verwendung ist auf den verlinkten Seiten zu finden.

Ziel
Der Adapter soll:

• Stabil laufen und sich Standardkonform verhalten
• möglich einfach und verständlich sein

Ich erhoffe mir Feedback zB zu

• Bugs, Error Logs;
• Verständlichkeit und Vollständigkeit der Doku
• Verwendbarkeit des Adapters, sind die Features brauchbar, was fehlt essentielles
• Code Reviews
• Erfahrungen aus dem Betrieb
• Ideen zur Geschäftslogik, zB werden aktuell Szenen DPTs von der Autoread Abfrage bei Start ausgeschlossen; gibt es bessere Filter?
• Verbesserungsvorschläge am Interface, z.B. welche State roles eignen sich für welche DPTs, sind die Datentypen passend gewählt, ...

Feature Anfragen, Fehlermeldungen dürfen gerne in GitHub erstellt werden. Umsetzung erfolgt immer nach Beschlusslage.

Wie schon erwähnt habe ich einen eigenen KNX Adapter erstellt. Die Entwicklung entstand aus einer Not heraus, da der verfügbare KNX Adapter meine Hardware nicht unterstützt. Ich sehe das Problem auch nicht behoben. Da ich einiges an Zeit investiert habe und der Adapter gut genug ist, bei mir im Haus die Arbeit zu übernehmen, möchte ich eine Vorstellung der Öffentlichkeit ankündigen.
Mein Adapter hat diese Architekturtreiber im Fokus:
-Einfach
-Dokumentiert und wartbar
-Standardkonform
(-Austauschbarkeit zum bestehenden Adapter)

Der Adapter basiert auf einem freien, gut getesteten KNX Stack.
Mein Adapter soll kein Ersatz für den bestenden KNX Adapter hier sein. Der Funktionsumfang soll sich auf das Notwendige beschränken und dies zuverlässig tun.
Der Adapter ist quelloffen und kommt mit einer Open Source Lizenz und ich hoffe auf guten Support vom Forum.
Über Weihnachten habe ich mir etwas Zeit reserviert das Vorhaben zu realisieren. Weiteres in einem eigenen Test Beitrag.
Wer Interesse an einem frühen DevDrop hat kann mir eine PM schreiben.

@percy Kann ich bestätigen, Unterstützung für latin1 baue ich ein..

@alcalzone danke, ich fixe die Findings vom Adapter checker zu einem der nächsten Releases

1 Fragen zum Adapter Check:
[E300] Not found on travis. Please setup travis
Ist es sinnvoll Travis aufzusetzen? Wie ich verstehe haben die massiv den Support für Open Source Projekte eingestellt und GitHub actions bietet eine ähnliche Funktionalität.

Version 0.1.3 ist jetzt verfügbar.

danke fürs die Rückmeldung,
Fazit: 0.1.3 ist nicht wirklich zu gebrauchen, ich hatte ein paar wichtige Use Cases nicht betrachtet
bitte auf die nächste Version 0.1.5 warten..

@frankthegreat said in Test Adapter OpenKNX 0.1.x:

Adapter wird nach der Installation grün, obwohl noch kein GW, Pi-Addr., PA eingetragen sind.
Nach eintragen der Daten in den Einstellungen wird der Adapter nicht mehr grün.
Fazit: Das sollte genau andersrum sein.

Bitte nochmal probieren mit 0.1.5
Hab da ein paar Verbesserungen eingebaut, wenn ich bei mir Ethernet kappe wird der Adapter gelb, bei Verbinden wird er wieder grün.
Sollte jetzt wesentlich besser sein.

Hab dann trotzdem versucht, meine GA's einzulesen, Export in XML kann man machen ist halt nicht mehr zeitgemäß.

Ja, warum?

Nach einer Stunde rumrödeln ohne Ergebniss...also in den Objekten wurde auch nichts angelegt, hab ich dann abgebrochen.
Der Importvorgang dauert <<1 Min, sonst ist es wie hier ein Problem. Da war noch ein Fehler drin, Neuinstallation habe ich vergessen zu testen. Sollte mit 0.1.5 gehen.

Obwohl der Adapter gelb ist, schreibt er dann ständig diese Warn-Meldungen ins Log:
Das ist ein Folgefehler

@mane444
sieht ja gut aus,
die Connection lost Meldung bei Startup ist noch ein Schönheitsproblem
mit 0.1.5 ist das Farbproblem gefixt. Temperaturen sind je nach DPT skaliert.

@nightwatcher
https://github.com/iobroker-community-adapters/ioBroker.openknx/issues/40
@ChrisChros
https://github.com/iobroker-community-adapters/ioBroker.openknx/issues/41

ich habe 2 issues dafür angelegt. Vielen dank

boellner created this issue in iobroker-community-adapters/ioBroker.openknx

closed filter comma from object names when importing ga #40

boellner created this issue in iobroker-community-adapters/ioBroker.openknx

closed modify warning log of unknown events #41

Hallo @nwh,

am besten du hängst noch ein Log aus der ETS an, dann kann ich Punkt 1 analysieren.

Punkt 2 habe ich nicht genau verstanden, du willst etwas mit dem Adapter senden? Um welchen Datentyp handelt es sich?

Version 0.8.0 ist jetzt verfügbar. Änderungen sind:

feature: put KNX interface name into log
bugfix: #419 wait for connection complete before data processing in case of receiving data before
bugfix: #457 Ack missing after changing IOB object value

Ok, ich mache es konfigurierbar.
Wenn sonst nicht ist wird die Testversion mit den Änderungen seit Anfang des Jahres die Stabile Version.

@tisp
schalte mal um auf loglevel alles und berichte. So in der Art:

openknx.0
2024-01-21 22:14:44.097	silly	States user redis pmessage openknx.0.*/openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach:{"val":3.3,"ack":true,"ts":1705871684096,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1705871564381}

openknx.0
2024-01-21 22:14:44.050	silly	[trace] 2024-01-21 21:14:44.050 (idle): UDP sent OK: TUNNELING_ACK 06100421000a04121400

openknx.0
2024-01-21 22:14:44.050	debug	Inbound GroupValue_Response from 1.1.240 GA 4/0/1 to Object openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach value: 3.3 dpt: DPT9.001

openknx.0
2024-01-21 22:14:44.050	debug	[debug] 2024-01-21 21:14:44.050 (idle): zzzz...

openknx.0
2024-01-21 22:14:44.050	silly	[trace] 2024-01-21 21:14:44.050 (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":18,"tunnel_endpoint":"192.168.0.10:3671","seqnum":20}}

openknx.0
2024-01-21 22:14:44.050	silly	[trace] 2024-01-21 21:14:44.049 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":23,"tunnstate":{"header_length":4,"channel_id":18,"seqnum":20,"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.240","dest_addr":"4/0/1","apdu":{"apdu_length":3,"apdu_raw":{"type":"Buffer","data":[0,64,1,74]},"tpci":0,"apci":"GroupValue_Response","data":{"type":"Buffer","data":[1,74]}}}}

openknx.0
2024-01-21 22:14:44.049	debug	[debug] 2024-01-21 21:14:44.049 Inbound message: 061004200017041214002900bce011f02001030040014a

openknx.0
2024-01-21 22:14:44.006	debug	Inbound GroupValue_Read from 1.1.134 GA 4/0/1 to openknx.0.Umwelt.Umwelt_Temperatur.Aussentemperatur_Dach

@hant0r ok, dann ist ja alles gut, oder?

@tisp relativ unwahrscheinlich dass ein genereller Fehler mit Temperatur bisher nicht aufgefallen wäre. Bei mir zB ist es plausibel. Falls du es nicht lösen kannst poste bitte mehr Daten z.B. SW Version, Werte von Signalen an den Schnittstellen etc.

@hant0r

Probiere mal die Version 0.7.2 von NPM, ich habe ein paar Verbindungsprobleme verbessert.

die Log Info von dir kommt wenn vom IOB etwas auf den Bus geschickt wird und es von keinem Empfänger bestätigt wird. Dann ist keiner in der ETS konfiguriert oder er hat ein Problem.

@hant0r
Nein ich meine hier, pro Objekt was auf Halde angelegt ist. In dem Zug kannst du die Objekte die nur von deiner Logik erzeugt werden gleich mit umstellen.

@hant0r said in Test Adapter OpenKNX 0.6.x:

Kann man das irgendwo deaktiveren?

Du kannst verhindern, dass es beim Start ausgelesen wird indem du

"autoread": false,

änderst.

die haben noch eine Ebene eingezogen bis die Daten kommen. Schau mal
https://github.com/boellner/ioBroker.luxtronik2
und berichte was passiert. Ich kanns es hier nicht testen.