Test Adapter OpenKNX 0.6.x

[tombox]

@killroy2 Wie gesagt ich entscheide nicht für den Nutzer was für ihn zu komplex ist oder nicht. Wenn er es zu komplex findet nutzt er es nicht.
Eine Checkbox ist noch kein Feature Creep außerdem ist das hier kein Industrieprodukt nach ISO Standard.
Ich denke du hast ein falsches Verständnis vom normalen ioBroker Anwender. Wenn er keine Möglichkeiten zum experiementieren wünscht dann würde er sich eine Gira X1 holen und fertig. Wenn es darum geht "normale" Nutzer zu schützen könnte man auch die nicht genehmigten Feature in Experimentier Tab auslagern

Ein Float wird als 800 anstatt 8,00 angezeigt ich denke damit kann man leben.

Ich verstehe nicht die Notwendigkeit jede Checkbox hinlänglich zu diskutieren um eine einzelne Person zu überzeugen, weil vielleicht ein Nutzer nicht weiß was die Checkbox bedeuten könnte oder weil vielleicht irgendwann ein Fehler auftreten könnte. Anstatt ein Betatest zu nutzen zu dem er da ist und wenn das Nutzerfeedback ist, das es Blödsinn ist, dann wieder rausnehmen. Anstatt das eine Person entscheidet was für alle gut oder schlecht sein könnte.

Es fördert auf jeden Fall nicht die Motivation mitzuarbeiten wenn am Ende nur eine Person entscheidet.

[killroy2]

@tombox Ein DPT9 Float hat ein spezielles Format für Mantisse und Exponent, das wird doch ohne Umrechnungsfunktion nie eine korrekte JS Number draus. Das mal als Beispiel stellvertretend für viele.

Mit der Umsetzung wie von dir vorgeschlagen implementiert er jetzt alles gegen Mixed Datentypen und ist von einer installation mit DPTs abgehängt. Mit seinen komplexeren Typen ist er aufgeschmissen, weil nicht mehr handelbar wie vorher oder oben beschrieben. Fixt er die ETS irgendwann wie geplant, kann er in IOB auf DPT korrigieren und hinterlässt eine Inkonsistente Struktur weil er nicht die abhägigen Einstellungen nicht kennt oder macht das über einen Reimport über die ETS und kann nachher seine ganze Applikation anfassen. Wie es zu gehen hat ist auch nicht dokumentiert. Ohne den Code anzuschauen versteht aktuell niemand was die Funktion tut.

Ich bin nicht gegen neue Features, aber sie sollen erstmal gut genug verstanden sein bevor wir sie auf die Menschheit loslassen. Auch in einer frühen Phase sollte man nichts einbauen was absehbar mal zu Frust führt.

[killroy2]

@killroy2 Zur Entscheidungsfindung gibts die GitHub issues. Dort kann auf breiterer Basis Notwendigkeit, technische Umsetzung und sonstige Details diskutiert werden.

[tombox]

@killroy2
Auf Github wird sich keine breite Diskussion entwickeln.
Es wird von einem Teil der Nutzer als Bug report genutzt. Diskussion finden hier im Forum statt.

Außerdem findet auf Github nur deine Entscheidungsfindung statt

Aber bringt nichts. Da nur du entscheidest was in den Adapter kommt dann ist es besser wenn nur du den Adapter weiter entwickelst und wie du gesagt hast wer eigene Feature will soll sich die selber bei sich einbauen.

[killroy2]

@tombox
Das ist eine Frage wie die Dinge gelebt werden. Jeder ist von mir aus herzlich eingeladen und auch weiter aktiv mitzuwirken. Es gibt noch viele Ideen zum Umsetzen.
Collaboration ist halt nunmal nicht ganz einfach wenn die Ausrichtung offen ist und nicht strikt nach Spec umgesetzt wird.
Wir brauchen einen gewissen Konsens was und wie es umgesetzt werden soll, und dazu hilft ein vorab eine Vorstellung mit Meinungsaustausch.
Wenn du das nicht valide hältst was ich oben geschrieben halst kannst du eine Gegenrede starten. Ab besten kanalisiert in einem Issue der alles thematisch umklammert.

[tombox]

@killroy2 Bisher sind alle Meinungsaustausche in "no I dont want this feature, please accept this" geendet von daher sind solche übertrieben Diskussion für jedes Minifeature Zeitverschwendung und dienen nur dazu das der Andere genervt aufgibt. Du machst das am besten alleine, dann ist das mit dem Konsens einfacher.

[Tontechniker]

@killroy2, @tombox Ich empfinde diese Diskussion als Zeitverschwendung!
Da bei mir in der ETS3 professionel keine Datentypen gesetzt waren, habe ich mich drangemacht, diese in allen DPTs einzutragen und dann zu exportieren. Nach dem Importieren in den Adapter hatte ich kaum noch Änderungen in den Objektdaten zu machen. Meiner Meinung nach müsste es reichen, die User bei Import aus alten ETS darauf hinzuweisen, dass die Datentypen vor dem Exportieren aus der "alten" ETS gesetzt werden müssen.

Sorry! Korrektur: Habe die ETS3 Aplikation mit "ETS-Projekt-Exporter" nach ETS5 exportiert, dort importiert und auch dort die Datentypen ergänzt. anschließend Die.xml erzeugt und diese in openknx importiert.*

[TheBam]

@tontechniker

Ich habe auch teils aus einer alten ETS version objekte importiert. Man kann ja auch die XML im Editor bearbeiten bzw. dort die werte hinzufügen und dann einfügen das geht auch. Sollte eigentlich auch für normale User möglich sein. Egal aus welcher ETS Version exportiert wird.

[tdoc]

Der Adapter findet auch in anderen foren Beachtung. Hier ein Zitat aus dem knx-user-forum.de:

https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/1628955-iobroker-knx/page3#post1722210

Du musst das "Beta (latest)" Repository aktiviert haben, dann findest du den openKNX Adapter.

Hier noch ein bissel Doku im ioBroker-Forum und github.
https://forum.iobroker.net/topic/503...-openknx-0-1-x

https://github.com/iobroker-communit...Broker.openknx

Konnte bisher ohne Probleme 898 GAs importieren. Du musst nur schauen das alle GAs die entsprechenden Datentypen gesetzt haben sonst werden die nicht importiert.

Das Problem mit dem fehlenden Import von GAs ohne DPT hat sich schon weitgehend rumgesprochen. Als Lösung empfiehlt sich, vor dem Import älterer Installationen eben passende DPT in der ETS zu ergänzen. Wenn das nicht gerade tausende Objekte sind, kann man das in ein paar Stunden Handarbeit auch erledigen. Automatisch wäre natürlich schöner, vielleicht kommt das noch.

[killroy2]

@tdoc said in Test Adapter OpenKNX 0.1.x:

Automatisch wäre natürlich schöner, vielleicht kommt das noch.

Hi Tdoc, ich würde das gerne anbieten. Alle Ansätze bisher brachten immer Nachteile und Gefahren mit sich die überwiegten. Der Ansatz den Aufwand, die ETS Datenbank - single source - einmal aufzuräumen scheint mir bisher der einzige gute Weg.
Ich bin für Vorschläge offen das doch noch zu implementieren. Bis dahin schreibe ich die Anleitung um.

[killroy2]

Neue Version 0.1.14 ist herausen.
Ein neues Hauptfeature ist drin, IP Interfaces werden jetzt automatisch detektiert und die Einstellungen übernommen. Einstellungen sind somit automatisch konsistent.
Alias Generierung ist etwas verbessert und die Gui ist etwas gereifter.
Falls das Gateway jetzt bei Systemstart wg. zu hoher Last aussteigt, gibt es jetzt richtigerweise eine Warnung um die Pausenzeit hochzusetzen.

• feature: create warning if DPT of alias pair does not match
• feature: create warning in log in case of possible data loss if gateway disconnects
• feature: better gui for import status, newline per warning, count number of succeeding ga's
• fix: local ip interface in admin was not taken
• fix: default regexp for status ga's corrected to match common nomenclature

[Automatisierer 0]

@killroy2
Adapter kann nicht deinstalliert werden:

--> Sorry: Habe einen Fehler gemacht, ist ja gar nicht installiert!!!

[Homer.J.]

@killroy2 Morgen, Frage wie lege ich über den Adapter die Alias an um eine Rückmeldung über den Status zu erhalten.
Grüße

[killroy2]

@homer-j Hi, über den Admin Dialog Reiter Alias. Die Einstellungen sollten einigermassen selbsterklärend sein. Eine bessere Hilfe kommt in der nächsten Version.

[Automatisierer 0]

@killroy2
Wo bitte finde ich das?
Hi, über den Admin Dialog Reiter Alias. Die Einstellungen sollten einigermassen selbsterklärend sein. Eine bessere Hilfe kommt in der nächsten Version.

[killroy2]

@automatisierer-0
über die Einstellungen vom Adapter

[tombox]

@killroy2
Ich denke die wichtige Importfunktion im leicht zu übersehende Tab ist ein UI Problem.
KNX Adapter macht das ja sogar automatisch.

Eine gute englische Hilfe gibt es es ja bereits, beim Klick auf das Fragezeichen, für die die es finden.

[killroy2]

neues Update ist heraus.
Die grösste Neuerung ist dass jetzt KNX Interfaces automatisch erkannt werden und die Einstellung vorgeschlagen wird.
Zweite Neuerung ist GroupValue_Read. Bisher konnte man ein KNX read nur über einen bestimmten, mitgegebenen Kommentar auslösen. Das Funktioniert mit dem Javaskript Adapter leider nicht, da er das Kommentarfeld überschreibt. Jetzt gibt es ein zweites Interface (q: qualityAsNumber 0x10). Mehr dazu steht im readme.

0.1.15 (2022-01-23)

• feature: more sanity checks for gui
• feature: issue #84, add openknx to discovery adapter
• feature: issue #82, warnings on import of duplicate ga addresses, also check iob object for duplicates
• fix: issue #87, added q interface to trigger GroupValue_Read, comments are overwritten in javascript adapter
• fix: remove currently unused reference to sentry

[killroy2]

Mittlerweile ist 0.1.17 herausen mit kleineren Verbesserungen.

[mane444]

@killroy2 Hi, ich hab die neue Version mal getestet. Hier ein kurzes Feedback:
Die automatische Suche nach dem KNX-Gateway geht bei mir nicht. Der Broker läuft bei mir allerdings im Docker mit eigener IP via Portainer. Nach dem Händischen eintragen der IP und Portadresse vom Gateway habe ich Verbindung.
Beim automatischen Erstellen der Alias habe ich festgestellt das nun Warnungen kommen:

openknx.0
2022-01-30 10:15:16.343	warn	create aliases: DPT1.011 does not match DPT1.001, consider defining a conversion function in the alias object

openknx.0
2022-01-30 10:15:16.342	info	create aliases: found match openknx.0.Licht.Schalten.DG_Licht_schalten and openknx.0.Licht.Schalten_Status.DG_Licht_schalten_Status

Meine Schaltaktoren haben den Schaltbefehl mit DPT1.001 und die Statusmeldung mit DPT1.011 vor belegt.
Wie schon geschrieben, soll nur eine kleine Rückmeldung zum Test sein. Ich finde den Adapter super gelungen.