NEWS
Test Adapter OpenKNX 0.6.x
-
@tombox
ich glaube mit der Änderung ist im nicht geholfen, er müsste sich dann selber um die Konvertierung der Datentypen (komplex zB Float) kümmern anhand von auch wieder nicht verfügbaren Regeln.@tdoc
DPTs bestehen aus einer
main number - mit dem Datentyp
und
subnumber (right) - mit Range + UnitZur Datenverarbeitung ist es notwendig den Datentyp zu kennen. Die subnumber ist optional.
Der ETS4 Export, sowohl im XML und CSV Format, erzeugt nicht die DPT Informationen.
Der Chefkoch Adapter nutzt ein proprietäres ETS Austauschformat und kann dort in den Tiefen nach den notwendigerweise Vorhandenen Informationen graben.
Gegen welche Konvention der openknx Adapter verstossen soll müsstest du schon aufzeigen denn ich sehe keine. Das Konzept der ETS4 wahr wohl eher keine externen Tools zu supporten.Du sagst du kannst zu ETS5 konvertieren. Wie sieht der XML Export dort ins eigene Format aus warum nimmst du den Output nicht von dort?
@tdoc
DPTs bestehen aus einer
main number - mit dem Datentyp
und
subnumber (right) - mit Range + UnitZur Datenverarbeitung ist es notwendig den Datentyp zu kennen. Die subnumber ist optional.
Der ETS4 Export, sowohl im XML und CSV Format, erzeugt nicht die DPT Informationen.
Der Chefkoch Adapter nutzt ein proprietäres ETS Austauschformat und kann dort in den Tiefen nach den notwendigerweise Vorhandenen Informationen graben.
Gegen welche Konvention der openknx Adapter verstossen soll müsstest du schon aufzeigen denn ich sehe keine. Das Konzept der ETS4 wahr wohl eher keine externen Tools zu supporten.Du sagst du kannst zu ETS5 konvertieren. Wie sieht der XML Export dort ins eigene Format aus warum nimmst du den Output nicht von dort?
Hier einfach mal ein Auszug aus meiner aktuellen ETS5, die ich auch für Änderungen,umparametrieren etc. benutze. Wie du siehst, fehlen fast überall die DPT. Das kommt vom ursprünglichen Projekt, damals gab es noch keine DPT. Es ist halt eine sehr alte Installation,hat ein Elektriker vor 20 Jahren gemacht. Konvertierung aus dem ursprünglichen Projekt in ETS5 liegt mir also vor und funktioniert auch völlig problemlos. Trotz der fehlenden DPT (die ich nur bei Bedarf mal nachträglich einpflege).
Es wäre also grundsätzlich schon eine große Hilfe für ALLE alten KNX-Installationen, wenn man auch ohne DPT deinen Adpater benutzen könnte. Insbesondere könnte man importieren, so geht es nicht ohne weiteres. Aber wie gesagt, ich hab trotzdem für mich eine Lösung gefunden und benutze deinen Adapter gerne. Er ist gut. Macht bitte weiter so!
-
@tdoc
DPTs bestehen aus einer
main number - mit dem Datentyp
und
subnumber (right) - mit Range + UnitZur Datenverarbeitung ist es notwendig den Datentyp zu kennen. Die subnumber ist optional.
Der ETS4 Export, sowohl im XML und CSV Format, erzeugt nicht die DPT Informationen.
Der Chefkoch Adapter nutzt ein proprietäres ETS Austauschformat und kann dort in den Tiefen nach den notwendigerweise Vorhandenen Informationen graben.
Gegen welche Konvention der openknx Adapter verstossen soll müsstest du schon aufzeigen denn ich sehe keine. Das Konzept der ETS4 wahr wohl eher keine externen Tools zu supporten.Du sagst du kannst zu ETS5 konvertieren. Wie sieht der XML Export dort ins eigene Format aus warum nimmst du den Output nicht von dort?
Hier einfach mal ein Auszug aus meiner aktuellen ETS5, die ich auch für Änderungen,umparametrieren etc. benutze. Wie du siehst, fehlen fast überall die DPT. Das kommt vom ursprünglichen Projekt, damals gab es noch keine DPT. Es ist halt eine sehr alte Installation,hat ein Elektriker vor 20 Jahren gemacht. Konvertierung aus dem ursprünglichen Projekt in ETS5 liegt mir also vor und funktioniert auch völlig problemlos. Trotz der fehlenden DPT (die ich nur bei Bedarf mal nachträglich einpflege).
Es wäre also grundsätzlich schon eine große Hilfe für ALLE alten KNX-Installationen, wenn man auch ohne DPT deinen Adpater benutzen könnte. Insbesondere könnte man importieren, so geht es nicht ohne weiteres. Aber wie gesagt, ich hab trotzdem für mich eine Lösung gefunden und benutze deinen Adapter gerne. Er ist gut. Macht bitte weiter so!
@tdoc
Du kannst doch die ganzen 1bit Werte in der ETS markieren und dann in den Eigenschaften auf z.B. 1bit Schalten stellen.
Das hat bei mir keine 30 minuten für 2000 GA gedauert -
@tdoc
Du kannst doch die ganzen 1bit Werte in der ETS markieren und dann in den Eigenschaften auf z.B. 1bit Schalten stellen.
Das hat bei mir keine 30 minuten für 2000 GA gedauert -
@tdoc
Du kannst doch die ganzen 1bit Werte in der ETS markieren und dann in den Eigenschaften auf z.B. 1bit Schalten stellen.
Das hat bei mir keine 30 minuten für 2000 GA gedauert@thorsten-missenberger
Ja natürlich gibt es für dieses Problem einige Lösungsmöglichkeiten. Allerdings werde ich auch nicht der einzige sein, der eine alte KNX-Installation am Laufen hat und dann erst mal vom vergeblichen XML-Importversuch frustriert ist. Für solche alten KNX-Installationen sollte es m.E. eben eine einfache Lösung geben (vielleicht auch nur einen Hinweis in der read.me). Am praktischsten wäre aber eine Checkbox, die eben einen raw Import zulässt (also ohne DPT) und trotzdem Objekte erzeugt (in Abhängigkeit von der Länge würde die Importprozedur halt bei 1 bit z.B. erst mal provisorisch Datentyp 1.000 erzeugen, das ist am einfachsten)Letztlich kommen die alten KNX-Installationen sehr gut ohne DPT aus. Jedes Gerät interpretiert eben die Rohdaten so, wie ihm vom Hersteller vorgegeben. Die DPT sind natürlich für die Übersichtlichkeit besser. Probleme gibt es aber erst, wenn andere Programme wie iobroker ins Spiel kommen und dann natürlich nicht wissen, was sie mit diesen Rohdaten anfangen sollen.
Grundsätzlich muss man aber so oder so Hand anlegen:
- entweder manuell in der knxproj Datei (und danach importieren)
- oder eben später manuell im iobroker (wenn es eine checkbox gäbe, die Rohdaten-Import zulässt)
Und grundsätzlich muss der user wissen, dass es bei alten KNX-Installationen dieses Problem geben kann und wie er es lösen muss.
-
@thorsten-missenberger
Ja natürlich gibt es für dieses Problem einige Lösungsmöglichkeiten. Allerdings werde ich auch nicht der einzige sein, der eine alte KNX-Installation am Laufen hat und dann erst mal vom vergeblichen XML-Importversuch frustriert ist. Für solche alten KNX-Installationen sollte es m.E. eben eine einfache Lösung geben (vielleicht auch nur einen Hinweis in der read.me). Am praktischsten wäre aber eine Checkbox, die eben einen raw Import zulässt (also ohne DPT) und trotzdem Objekte erzeugt (in Abhängigkeit von der Länge würde die Importprozedur halt bei 1 bit z.B. erst mal provisorisch Datentyp 1.000 erzeugen, das ist am einfachsten)Letztlich kommen die alten KNX-Installationen sehr gut ohne DPT aus. Jedes Gerät interpretiert eben die Rohdaten so, wie ihm vom Hersteller vorgegeben. Die DPT sind natürlich für die Übersichtlichkeit besser. Probleme gibt es aber erst, wenn andere Programme wie iobroker ins Spiel kommen und dann natürlich nicht wissen, was sie mit diesen Rohdaten anfangen sollen.
Grundsätzlich muss man aber so oder so Hand anlegen:
- entweder manuell in der knxproj Datei (und danach importieren)
- oder eben später manuell im iobroker (wenn es eine checkbox gäbe, die Rohdaten-Import zulässt)
Und grundsätzlich muss der user wissen, dass es bei alten KNX-Installationen dieses Problem geben kann und wie er es lösen muss.
@tdoc said in Test Adapter OpenKNX 0.1.x:
Die Länge 1 bit sieht der Adapter nicht, weder beim Import noch auf dem Bus.
Erstmal gehts darum überhaupt Daten in IOB zu bringen, aktuell verweigert sich der Adapter.
Ich weiss nicht wie gut dir da der "Rohwert" (das ist ein Bytearray) hilft.-Für boolsche Werte kriegst du ein 1 Byte grosses Interface. Willst du später die DPTs korrigieren musst du überall in deinen Applikationion auf neuen Schnittstellen umstellen.
-Alle anderen Datentypen sind ohne händische Eingabe in der ETS oder im Objekt eh nicht nutzbar, ausser du willst dich selber um die Dekodierung der Datentypen kümmernEs deshalb weniger problematisch das Feature mit einer Checkbox umzusetzen die besagt "importiere GAs ohne DPT Zuweisung als Logikwert"
Ist der Wert auf dem Bus >1Byte kommt eine Warnung und wird ignoriert, und alle 1 Byte Werte !=0 werden als true interpretiert. -
@tdoc said in Test Adapter OpenKNX 0.1.x:
Die Länge 1 bit sieht der Adapter nicht, weder beim Import noch auf dem Bus.
Erstmal gehts darum überhaupt Daten in IOB zu bringen, aktuell verweigert sich der Adapter.
Ich weiss nicht wie gut dir da der "Rohwert" (das ist ein Bytearray) hilft.-Für boolsche Werte kriegst du ein 1 Byte grosses Interface. Willst du später die DPTs korrigieren musst du überall in deinen Applikationion auf neuen Schnittstellen umstellen.
-Alle anderen Datentypen sind ohne händische Eingabe in der ETS oder im Objekt eh nicht nutzbar, ausser du willst dich selber um die Dekodierung der Datentypen kümmernEs deshalb weniger problematisch das Feature mit einer Checkbox umzusetzen die besagt "importiere GAs ohne DPT Zuweisung als Logikwert"
Ist der Wert auf dem Bus >1Byte kommt eine Warnung und wird ignoriert, und alle 1 Byte Werte !=0 werden als true interpretiert.@killroy2
Auch nicht boolsche Werte werden gut angezeigt und sind nutzbar, es gibt kein Grund es auf Logikwerte zu begrenzen.
Ich denke der Nutzer sollte hier entscheiden was er wie nutzen möchte und man sollte ihn nicht beschränken weil man denkt er könnte vielleicht damit nicht umgehen. -
@killroy2
Auch nicht boolsche Werte werden gut angezeigt und sind nutzbar, es gibt kein Grund es auf Logikwerte zu begrenzen.
Ich denke der Nutzer sollte hier entscheiden was er wie nutzen möchte und man sollte ihn nicht beschränken weil man denkt er könnte vielleicht damit nicht umgehen.@tombox
Zu komplex, der Nutzer hat einen Haufen arbeit hat eine falsch verstandene Funktion nachher auszubügeln. Wenn man jedes erdenkbare Szenario abbilden möchte haben wir nachher einen frei programmierbaren Adapter und den Feature Creep. Womöglich will jemand Zugriff auf die ceimi Rohdaten? Oder, oder..
Wir brauchen verständliche Funktionen für einen normalen Anwender, wer experimetieren will baut sich das selber ein.Ein Float, ein Datum etc pp wird nie richtig angezeigt. Ich kennen keinen Use Case mit den Rohwerten was anfangen zu müssen. Der Use Case hier ist: importier mir die Daten mit Gewalt, zu Typen mit denen der Adapter nichts anfagen kann werde ich gewarnt und setze manuell
-
@tombox
Zu komplex, der Nutzer hat einen Haufen arbeit hat eine falsch verstandene Funktion nachher auszubügeln. Wenn man jedes erdenkbare Szenario abbilden möchte haben wir nachher einen frei programmierbaren Adapter und den Feature Creep. Womöglich will jemand Zugriff auf die ceimi Rohdaten? Oder, oder..
Wir brauchen verständliche Funktionen für einen normalen Anwender, wer experimetieren will baut sich das selber ein.Ein Float, ein Datum etc pp wird nie richtig angezeigt. Ich kennen keinen Use Case mit den Rohwerten was anfangen zu müssen. Der Use Case hier ist: importier mir die Daten mit Gewalt, zu Typen mit denen der Adapter nichts anfagen kann werde ich gewarnt und setze manuell
@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 auslagernEin 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 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 auslagernEin 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.
@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.
-
@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 Zur Entscheidungsfindung gibts die GitHub issues. Dort kann auf breiterer Basis Notwendigkeit, technische Umsetzung und sonstige Details diskutiert werden.
@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
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.
@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
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.@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.
-
@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.
@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.*
-
@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.*
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.
-
Der Adapter findet auch in anderen foren Beachtung. Hier ein Zitat aus dem knx-user-forum.de:
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-xhttps://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.
-
Der Adapter findet auch in anderen foren Beachtung. Hier ein Zitat aus dem knx-user-forum.de:
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-xhttps://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.
@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. -
Aktuelle Testversion v0.7.3-alpha.1 Stabile Version: 0.6.3 Erstveröffentlichungsdatum 16.12.2021 Github Link https://github.com/iobroker-community-adapters/ioBroker.openknx/ NPM Link https://www.npmjs.com/package/iobroker.openknx Issues Board in GitHub https://github.com/iobroker-community-adapters/ioBroker.openknx/issues Installation der Testversion
"Adapter", "Expertenmodus", "Octocat", "Benutzerdefiniert" und diesen Link:
https://github.com/iobroker-community-adapters/ioBroker.openknx.gitAdapter 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
Thema umgesetzt ab Version Erwartung Release 0.1.x Release im stable repository Installation 0.1.6 Adapter lässt sich fehlerfrei über NPM installieren Installation 0.1.9 Adapter lässt sich über IOB Bordmittel installieren Betrieb 0.1.6 Adapter zeigt den Betriebszustand (rot,gelb,grün) korrekt an, bei Verbindungsabbrucht wird der Adapter gelb, keine Warnungen im Log die nicht zum Zustand passen Betrieb 0.1.8 keine Warnungen im Log die nicht zum Zustand passen Übersetzung 0.1.8 Admin Dialoge in alle Sprachen übersetzt, Logs nicht Alias 0.1.11 Generierung von Alias zur Zusammenbringen von Status und Ausgabe-GA zu einem Objekt eingebaut, noch nicht fehlerfrei 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.
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
-
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
@killroy2
Adapter kann nicht deinstalliert werden:
--> Sorry: Habe einen Fehler gemacht, ist ja gar nicht installiert!!!
-
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
Support us
666
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge