CLI tools als ETS Alternative

[henfri]

Der Vergleich hinkt etwas, aber ok. Nur weil sie es nicht mehr verkaufen, verschwindet die ETS nicht von allen PCs...

Meine wird dann dank Cloud Lizenz leider nicht mehr funktionieren.
Hatte ich bisher gar nicht drüber nachgedacht.

[traxanos]

Wäre die Schnittstelle offen gewesen

Die Schnittstelle ist doch offen, hilft dir aber nichts. Ein KNX Gerät besteht aus einer Firmware und einer Applikation (welche mit der ETS verwaltet wird).

hätte man die Geräte weiterverwenden können

Nein hätte man nicht, weil niemand sich monate Lang hinsetzt und eine alternative für ein komplexes Gerät nachbaut. Offen ist etwas theoretisches.

Mit etwas Glück hätte die Open Source Community sogar ein Alternatives GUI hervorbringen können.

Kannst du auch jetzt schon. Den Aufwand betreibt aber bisher niemand weil es ebene. Wenn man von den Plugins mal absieht, ist das alles nur XML.

Deshalb ist für mich der "API-First" Ansatz ja eine Zwingende Voraussetzung für einen zukunftssicheren Betrieb.

Der "API-First" Ansatz ist ein Grund für soviel Elektroschrott auf diesem Planeten. APIs ändern sich schneller als den meisten recht ist.

Und auch eine API nutzt eine Technologie die ggf morgen obsolete ist. Was machst du denn wenn wir morgen alle nur noch IPv6 nutzen? Dann klappt deine API auf IPv4 Basis auch nicht mehr.

Fakt ist, KNX ist älter als jeder API-First-Ansatz. Fakt ist, KNX ist älter als Webtechnologie brauchbar existierte. Fakt ist, ich kann (bis auf wenige Ausnahmen) heute noch Gebäudeinstallationen verwalten, wo viele Menschen mit dem "API-First-Ansatz" nichtmal geboren waren

Aber Fakt ist auch, das die ETS Nachteile hat inkl. Verbesserungspotential.

Aber ich glaube du lebst in der "Web"-Bubble und das hier trifft auf die voll kommen zu:

KNX ist nix für Dich, solange Du das Paradigma und das Prinzip nicht verstanden hast, das ist richtig.

[Springrbua]

Die ETS in der Eigenschaft, das es genau nur ein Programm gibt mit dem soweit ALLE KNX Geräte die es gibt und bisher gegeben hat einheitlich zu bearbeiten sind, ist genau das Killerfeature von KNX.

Dass die ETS als Killerfeature von KNX (im positiven Sinn) bezeichnet wird, habe ich auch noch nicht oft erlebt

Ich verstehe die Frage und den Wunsch von VanCoding ganz gut und sehe prinzipiell auch nichts was dagegen spricht.
Wenn ich z.B. eine Spreadsheet-Datei im OpenDocuments Format habe, habe, kann ich diese sowohl mit Excel, als ach mit OpenOffice, Google Docs etc. öffnen, unabhängig davon mit welchem Programm sie erzeugt wurde.
Das Programm ist nur ein Werkzeug, das Format (der "Standard") ist entscheidend.

weil man dem Gerät ja erst mal sagen muss was seine Funktionen sind... also die Applikation bauen.

Wenn dabei jedes Gerät bzw. die Produktdatenbank nur eine Beschreibung liefert (also welche Parameter es gibt und wie sie zu gruppieren sind) dann könnte diese Beschreibung in jeder Software genutzt werden um die "Applikation" aufzubauen. Das wird aber vermutlich nicht so sein oder?

Die zentralisierte Konfigurationsschicht ist imho das größte Manko an KNX. Geschuldet ist das bestimmt dem Alter und der damals verfügbaren Geräteresourcen.

Bei KNX haben wir hier eine kleine Zwickmühle, da die Software auch mit alten Geräten kompatibel sein muss. Natürlich ist diese jahrzehntelange Kompatibilität ein großer Pluspunkt für KNX, gleichzeitig bremst es aber auch den Fortschritt in gewisser Weise ein.
Ich habe mir kürzlich ein Matter-Gerät (Smart Plug) gekauft und war erstaunt wie einfach die Einrichtung da ging. Gerät einstecken, QR-Code scannen und schon war das Gerät mit WLAN verbunden und eingerichtet.
Ich will hier jetzt nicht KNX mit Matter vergleichen nur denke ich, dass man auch in KNX mittlerweile Dinge anders machen würde, wenn man nicht rückwärtskompatibel bleiben müsste.

Und nur so als Info am Rande:
Diese Idee kam auch in XKNX schon mal auf:
https://github.com/XKNX/knx-frontend...omment-7780808

[Ing-Dom]

Meine wird dann dank Cloud Lizenz leider nicht mehr funktionieren.
Hatte ich bisher gar nicht drüber nachgedacht.

Nun, genau deswegen hab ich einen Dongle. Und ganz grundsätzlich, für den Notfall weiß ich wo man eine "Lösung" dafür im Netz findet ..

Der Name "OpenKNX" hatte bei mir halt einfach die Hoffnung geweckt, dass KNX inzwischen nun vielleicht doch etwas für mich ist.

OpenKNX entwickelt komplett offene Firmware für KNX-Geräte (frei und offen, im Sinne der GPLv3), dazu ebenfalls noch offene Hardware und auch PC-Tools.

An eine offene Alternative zur ETS ist aktuell nicht zu denken. Die Gründe finden sich im Thread.
Eine offene Konfigurations-Software nur für OpenKNX-Geräte wäre vorstellbar, aber genau das will ICH eigentlich nicht.

Die Stärke von KNX ist eben diese Interoperabilität zwischen den vielen, vielen Herstellern. Dafür nehme ich dann auch die Nachteile in Kauf..

Du kannst gerne mit der Implementierung einer freien alternative zur ETS beginnen. Wir helfen auch. Und das kann sicher auch Teil des OpenKNX Projekts werden.
Ich glaube aber kaum, dass dies realistisch ist.
Falls du eine reiche Erbtante hast und 1 Mio übrig, können wir weiter reden

[henfri]

Eine offene Konfigurations-Software nur für OpenKNX-Geräte wäre vorstellbar, aber genau das will ICH eigentlich nicht.

Das wäre Konnekting, oder?

[meti]

Wenn dabei jedes Gerät bzw. die Produktdatenbank nur eine Beschreibung liefert (also welche Parameter es gibt und wie sie zu gruppieren sind) dann könnte diese Beschreibung in jeder Software genutzt werden um die "Applikation" aufzubauen. Das wird aber vermutlich nicht so sein oder?

Soweit ich das sehe ist das schon so, ja.

[traxanos]

Soweit ich das sehe ist das schon so, ja.

Genau das ist nur eine XML. Zumindest im Normalfall. Eingie Hersteller bzw. Produkte liefern ganze Anwendungen mit, so z.B. das ABB Logikmodul. Diese sind halt Closesource. Das bekommst du halt nicht auf andere Plattformen.

[meti]

Wie das mit DCAs ist weiß ich nicht so genau. Sind das kompilierte Blobs?

[traxanos]

Davon ist auszugehen, mir ist nichts imn XML bekannt womit man das abbilden könnte. Die Sachen werden dann als Baggages eingebunden.

[Ing-Dom]

Das wäre Konnekting, oder?

nein, Konnekting hat eine eigene XML Spezifikation "erfunden". Eine ganz einfache.
Und die passende Suite dazu. Die ETS konnte damit nicht anfangen, und die Parametrierung lief über eine spezielle Gruppenadresse.

OpenKNX Geräte sind (weitgehend) spezifikationskonforme SystemB Devices...

Und worauf ich hinauswollte, wenn man sich in der "OpenETS" darauf beschränkt dass man nur OpenKNX Geräte supportet, dann täte man sich viel, viel leichter. Trotzdem noch eine Mammutaufgabe.

[thewhobox]

DCAs sind nichts weiter als dlls, die von der ETS geladen werden.
Plugins sind externe Anwendungen, die die ETS auf dem Windows PC startet.

Das wird aber vermutlich nicht so sein oder?

Doch das geht. Der Aufwand dahinter ist aber immens!

Das Programm ist nur ein Werkzeug, das Format (der "Standard") ist entscheidend

Und dann hat plötzlich LibreOffice Funktionen integriert, die gar nicht im Standard sind, die aber Benutzer XY unbedingt verwenden will.
Und schon kannst du das nicht mehr in die anderen importieren.
Siehe Matter. Da passiert genau das. Die Produkte funktionieren mit der Hersteller APP in allen Funktionen, aber per Matter fehlen Sachen, weil es sie so dort nicht gibt.

Und genau dieses Probleme sehe ich dann auch bei mehreren öffentlichen ETS alternativen.
Die eine benutzt GAs 3stufig, die andere Arbeitet nur mit Funktionen, die nächste verwaltet sie frei...
Das sind Sachen, die der Standard eben nicht vorgibt und worüber es verschiedene Meinungen gibt.


Aber nochmal:
Wir hindern niemanden daran so etwas zu entwickeln und als OpenSource zur Verfügung zu stellen


Gruß Mike

[VanCoding]

Die ETS is keine Software eines Herstellers.

Aus Benutzersicht ist es eigentlich ziemlich egal wer die Software herausgibt. Der springende Punkt ist, dass es keine Alternative dazu gibt, und auch keine geben kann. Du bist zu jeder Zeit vom Softwarehersteller abhängig. Gibt es einen Bug, bist du darauf angewiesen, dass dieser den behebt. Wenn er will kann er dafür so viel Geld nehmen wie er will, ist ja alternativlos.

Die Schnittstelle ist der Bus, und der ist offen. Das ist ja das tolle.
jeder, auch jedes Unternehmen kann seine eigene Software entwickeln, die auf dem Bus operiert. Macht nur keiner, weil...

Der Bus ist offen ja, aber das nützt dir halt nichts wenn du die Geräte nicht so konfigurieren kannst, dass sie darüber miteinander kommunizieren können.
Die "Verknüpfung" der Geräte ist ein Kernbestandteil von KNX, ohne die das System nicht funktionieren kann. Damit ich ein System als offen bezeiche, müssen alle Kernbestandteile davon offen sein.

Ich glaube man muss sich da nichts vor machen: Man braucht derzeit eine "Erlaubnis" um seine Geräte (die man gekauft hat und einem gehören) in Betrieb zu nehmen und zu verwenden. Diese Erlaubnis kann zwar mit zusetzlichem Geld erworben werden, hinterlässt bei mir aber ein sehr bitteren Nachgeschmack.

Siehe Matter. Da passiert genau das. Die Produkte funktionieren mit der Hersteller APP in allen Funktionen, aber per Matter fehlen Sachen, weil es sie so dort nicht gibt.

Irgendwie sehe ich da das Problem nicht ganz. Wenn du weisst, du möchtest ein Gerät in KNX einbinden, dann ist doch egal was das Gerät sonst noch kann. Wichtig ist, was es per KNX kann. Wenn es deine Anforderungen per KNX nicht erfüllen kann, kaufst du es halt nicht. Dann gibt's sicher was von der Konkurrenz.

LibreOffice finde ich übrigens ein ziemlich schlechtes Beispiel. Dort wird der Standard ja von keiner zentralen Instanz vorgegeben. Da ist es nur logisch, dass man versucht mit einer Abweichung vom Standard der Konkurrenz zu schaden. Bei Standards ist eine zentrale Instanz aber sehr wichtig! Idealerweise ist diese Instanz aber nicht in irgendeine Implementation involviert und komplett neutral. Dies ist jetzt z.B. bei KNX nicht der Fall.

[Springrbua]

Und dann hat plötzlich LibreOffice Funktionen integriert, die gar nicht im Standard sind, die aber Benutzer XY unbedingt verwenden will.
Und schon kannst du das nicht mehr in die anderen importieren.

Aber weiterhin kann das Ganze im Standard-Format gespeichert und somit mit anderen Programmen auch geöffnet werden.
Die proprietäre Funktion geht dabei zwar verloren, aber die restlichen 99% funktionieren weiterhin.

Die Produkte funktionieren mit der Hersteller APP in allen Funktionen, aber per Matter fehlen Sachen, weil es sie so dort nicht gibt.

Aber genau das Problem hast du jetzt mit der ETS ja auch schon in gewisser Weise.
Beispiel:
Der Benutzer möchte beim MDT Glastaster Smart eigene Icons hinterlegen.
Die ETS kann das von Haus aus nicht bzw. ist dafür in der Applikations-Definition nichts vorgesehen, also gibt es eine DCA.
Die DCA ist ja in gewisser Weise auch wieder eine proprietäre Software die in dem Fall halt von der ETS und nicht von Windows aus gestartet wird.

Die eine benutzt GAs 3stufig, die andere Arbeitet nur mit Funktionen, die nächste verwaltet sie frei...

Für den BUS sind die GAs ja immer frei, Gruppen gibt es nur in der ETS. Das ist also eine Darstellungssache, die dann mMn auch jede Software für sich entscheiden kann. Wichtig ist, dass die Projektdatei einem Standard entspricht und somit von allen Programmen geladen werden kann.
Natürlich wäre die Gruppierung in dem Fall ein Zusatzfeature einer Software, aber sowas hat man z.B. auch bei SVG-Dateien. Wenn ich diese z.B. mit Inkscape verändere werden Inkscape-Spezifische Eigenschaften dazu geschrieben. Das SVG entspricht aber weiterhin dem Standard, der diese Eigenschaften einfach ignoriert.

Wir hindern niemanden daran so etwas zu entwickeln und als OpenSource zur Verfügung zu stellen

Ich hoffe das Ganze hier wird nicht als Aufforderung oder gar Kritik an OpenKNX verstanden, es war ja lediglich die Frage ob es eine Alternative gibt.
Also um das klarzustellen, ich bewundere das was ihr hier macht und bin, auch wenn ich bisher leider noch keines der Geräte selbst im Einsatz habe, dankbar für euer Engagement.
Mir ist auch klar, dass das meiste was zu diesem Thema geschrieben wird Theorie bleiben wird. KNX ist dafür vermutlich zu "unbekannt" und der Bedarf an einer ETS Alternative zu klein als dass sich hier größere Entwicklergruppen (die es sicher brauchen würde) zusammenschließen um diese Alternative zu entwickeln und zu pflegen.

[Ing-Dom]

Der springende Punkt ist, dass es keine Alternative dazu gibt, und auch keine geben kann. Du bist zu jeder Zeit vom Softwarehersteller abhängig. Gibt es einen Bug, bist du darauf angewiesen, dass dieser den behebt. Wenn er will kann er dafür so viel Geld nehmen wie er will, ist ja alternativlos.

Sehe ich anders - es kann durchaus eine Alternative geben! Ich sehe - außer dem immensen Aufwand - keinen Hindernisgrund warum man kein alternatives Knfigurationstool schreiben können soll.

thewhobox hat das ja bereits demonstriert dass es grundsätzlich möglich ist !

[mumpf]

Dafür wollte ich einfach mal Danke sagen.

Danke Roman, dass ich mal wieder lachen durfte .

Dass die ETS als Killerfeature von KNX (im positiven Sinn) bezeichnet wird, habe ich auch noch nicht oft erlebt

Doch, genau deswegen gibt es OpenKNX. Die ETS ist der Projektverwalter, die Gesamtübersicht Deiner Installation und damit der "Source-of-Truth". Uns war es wichtig, dass unsere Geräte auch dort vertreten sind und man alle Verknüpfungen - auch mit nicht-OpenKNX-Geräten - sehen kann. Eine eigene Konfigurationssoftware scheidet somit aus.

Das wäre Konnekting, oder?

Nein, Konnekting hat ein eigenes Protokoll zum Konfigurieren und eine Software, die nur Konnekting-Geräte kann. Also genau das, was wir in OpenKNX vermeiden wollen.

Wenn dabei jedes Gerät bzw. die Produktdatenbank nur eine Beschreibung liefert (also welche Parameter es gibt und wie sie zu gruppieren sind) dann könnte diese Beschreibung in jeder Software genutzt werden um die "Applikation" aufzubauen.

Das XML der Produktdatenbank ist genau so etwas. Aber es ist weit mehr, als ein paar Parameter "gruppieren". Es beschreibt das gesamte Verhalten der Gerätes in Abhängigkeit der Parameter und auch welche Abhängigkeiten die UI-Objekte haben, wie die Speicherstruktur auf dem Gerät aussieht, welche Bytes und Bits (ja, Bits) nach welchen Regeln wie beschrieben werden, welches Protokoll für die Programmierung verwendet wird, ob bestimmte Daten sortiert oder tabellarisch oder wie auch immer geliefert werden müssen, was bei einem Update passiert, welche Interaktionen mit den Parametern möglich sind usw.
Natürlich kann man so was nachprogrammieren, frag thewhobox, er hat es versucht . Oder frag meti, er hat für HA "nur" die Parameter rausgeparsed.

Wie das mit DCAs ist weiß ich nicht so genau. Sind das kompilierte Blobs?

Das sind auf jeden Fall .NET-Programme, die Out-Of-Process in der ETS laufen.

Gibt es einen Bug, bist du darauf angewiesen, dass dieser den behebt. Wenn er will kann er dafür so viel Geld nehmen wie er will, ist ja alternativlos

Du hast ein simples Hersteller-Software-Bild im Kopf. Das ist hier nicht so. Bei KNX hast Du die Hersteller (Hardware, Firmware und ETS-Applikation), die KNXA (KNX-Standard und ETS), also 2 Organisationen.
Und wenn der Hersteller einen Bug hat und den nicht behebt, kaufe ich einfach ein KNX-Gerät eines anderen Herstellers. Und wenn die ETS einen Bug hat, werden die Hersteller schon bei der KNXA hinterher sein, dass dieser behoben wird, denn die wollen ja ihre Produkte verkaufen.

Gruß, Waldemar

P.S.: Genauer: Und wenn der Hersteller einen Bug hat und den nicht behebt, dann mach ICH was besseres als OpenKNX-Projekt (siehe Steinel TP) und mein VPM.