CLI tools als ETS Alternative

[VanCoding]

Hallo zusammen

Ich finde KNX grundsätzlich eine ziemlich spannende Sache, für die es leider kaum gescheite Alternativen gibt.
Dennoch gibt es Punkte, die mich daran dermassen stören, dass ich davon bisher Abstand genommen habe:

- ETS ist kostenpflichtig
- ETS ist nicht open source
- ETS ist nicht plattformunabhängig, läuft nur unter Windows, Linux wird nicht unterstützt
- ETS ist die einzige Software, mit der man sein KNX System konfigurieren kann

Auch wenn es also möglich ist Komponenten für das KNX-System zu entwickeln, ist KNX meiner Meinung ein geschlossenes, proprietäres System.
ETS werde ich in seiner aktuellen Form nicht nutzen.

Jetzt habe ich aber gesehen, dass es OpenKNX gibt und mich sofort gefragt: Habt ihr auch schon irgendeine Alternative zu ETS?

Konkret würde ich mir ein CLI wünschen, mit dem ich
- Geräte auflisten kann
- Geräte Adressen setzen kann
- Geräte-Funktionen und deren aktuelle Gruppen-Adresse auflisten kann
- Geräte-Funktionen eine neue Gruppen-Adresse zuordnen kann

Gibt es schon sowas, oder denkt ihr es wäre möglich sowas zu entwickeln?

[gbglace]

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.

Was bringen einem zig verschiedene Softwareangebote die dann immer kommen und gehen und immer nur einen Ausschnitt an den verfügbaren KNX-Geräten beherrschen zu programmieren. Und wie bitte willst Du das mit KNX-Secure machen? Da fangen die Hersteller dann auch noch schneller an sich ständig neues einfallen zu lassen um inkompatibel zu werden.

Ja es gibt eine zentrale Stelle wo alle KNX Geräte durch müssen, um quasi Kompatibilität zum KNX-Bus zu beweisen. Und diese Stelle stellt damit auch das eine Werkzeug bereit.

Aber einige Gerätehersteller bieten da immer Ihre eignen ergänzenden Inbetriebnahmeprogramme an. Und genau deswegen kaufe ich diese nicht (ABB iBus tool) oder versuchen zunehmend ihre Programmierungen in eine bluetooth app zu verlagern (Steinel). Das sind für mich direkt Kandidaten für Gerät wird nicht gekauft. Weil das alles nicht langzeitstabil ist und eben wirklich proprietär.

ist KNX meiner Meinung ein geschlossenes, proprietäres System.

jedem seine Meinung

ETS werde ich in seiner aktuellen Form nicht nutzen.

Dann wirst auch noch für reichlich weitere Jahre kein KNX nutzen.

Allein wenn ich mir HA anschaue für mich ein Kraut und Rübenladen an unterschiedlichsten Adapterformen. Einfach keine Einheitlichkeit, bis auf das es YAMLs gibt.
Ich will da in solch einem Durcheinander kein Opensource haben.

Und Preisdiskussionen gibt es jede Woche und sind im Rahmen einer Vollinstallation eines EFH nur Jammern.

Einzig wo man drüber nachdenken könnte ist eine Verfügbarkeit auf anderer Basis als Windows. allerdings verliert man dann viel an Rückwärtskompatibilität von Geräten die da so manch exotisches Plugin benötigen, denn dann müssten auch die Hersteller diese Komponenten anpassen um noch zu funktionieren. Also insgesamt eher unwahrscheinlich.
Und welche sinnvolle Basis wäre es denn sonst Apple im PC markt kann es ja nun nicht sein, ist ja nur ne Niesche, da lohnt kein Aufwand. Aber auch diese Diskussion gab es erst letzte Woche hier irgendwo im Forum. was denn eine tolle OS Plattform für die ETS wäre und warum das eher nicht zu erwarten ist.


Anders gefragt bei welcher Sorte Geräte werden denn Deine Wünsche oben erfüllt, da fällt mir aber sogleich auch gar nichts ein, was nicht gleich ESP Bastel-HW ist.
Da bin ich doch sehr froh das die OpenKNX-HW an der Stelle sich in die Fähigkeiten der ETS integrieren und ich und im Zweifel auch mal ein Dienstleister wenn ich nicht mehr bin das gerät weiter bearbeiten kann. Wer soll sich dann bitte wieder in unterschiedlichste Programme einarbeiten?

KNX ist an der Stelle immer noch vom Anspruch her ein professionelles Umfeld, da gelten ganz andere Kriterien als der private Bastel und Sparwille.

Ansonsten der KNX Standard ist offen einsehbar, kannst ja loslegen. Musst halt die Applikationsdatenbanken der Hersteller reverse entwickeln, um dann das passende Menü auf der Oberfläche zu basteln. Dazu zumindest gab es schon Ansätze. Aber zu einem ETS-Ersatz hat da noch nix geführt.

[VanCoding]

ist genau das Killerfeature von KNX

Sehe ich anders. Das Bus-Protokoll und die dezentrale Natur von KNX ist das Killerfeature. Die Konfiguration ist aktuell der Nachteil.

allerdings verliert man dann viel an Rückwärtskompatibilität von Geräten die da so manch exotisches Plugin benötigen

Das ist bereits eines der Probleme. Wäre das ganze offen, könnte eine Kompatibilität ganz einfach hergestellt werden. Sonst wird das Gerät einfach unbrauchbar, sobald selbst ETS den Support entfernen muss.

Und welche sinnvolle Basis wäre es denn sonst Apple im PC markt kann es ja nun nicht sein, ist ja nur ne Niesche, da lohnt kein Aufwand.

Wenn mans richtig macht ist Software automatisch platformunabhängig, ganz ohne Aufwand. Das wurde bei ETS einfach verschlampt. Die richtige Lösung wäre wohl ohnehin ein Web-Basiertes UI, das immer erreichbar ist.

Anders gefragt bei welcher Sorte Geräte werden denn Deine Wünsche oben erfüllt, da fällt mir aber sogleich auch gar nichts ein, was nicht gleich ESP Bastel-HW ist.

Es gibt viele Geräte, die kann ich ganz einfach per HTTP konfigurieren (z.B. Shellies). Da brauche ich keine proprietäre Software vom Hersteller, die auch noch Geld kostet und mir vorschreibt welches Betriebssystem ich nutzen muss.

Aber die haben natürlich auch alle ihre Nachteile, weshalb ich ja meine, dass es für KNX kaum gescheite Alternativen gibt.

KNX ist an der Stelle immer noch vom Anspruch her ein professionelles Umfeld, da gelten ganz andere Kriterien als der private Bastel und Sparwille.

Meine Bedürfnisse haben eigentlich nichts mit basteln oder sparen zu tun. Wenn die Software nicht offen ist, gibt es keine Garantie, dass ETS auch in Zukunft zu einem erschwinglichen Preis (oder überhaupt!) verfügbar sein wird. Wenn die ETS einstellen wollen, können die das jederzeit tun. Alle gekauften Geräte werden dadurch quasi Briefbeschwerer, da nicht mehr ansteuerbar.

Wer soll sich dann bitte wieder in unterschiedlichste Programme einarbeiten?

Wenn es Alternativen gibt, heisst das nicht, dass ETS nicht wie bisher alle Geräte konfigurieren kann. Es heisst lediglich, dass es auch mit anderen Programmen geht. Wenn du ETS kennst ist das ja gut und du brauchst nichts zusätzliches. Wenn man ETS nicht nutzen will, ist es aber schön Alternativen zu haben.

Musst halt die Applikationsdatenbanken der Hersteller reverse entwickeln, um dann das passende Menü auf der Oberfläche zu basteln.

Dann gibt es also noch keinen offenen Standard, bzw. Standardisiertes Format mit dem die "Funktionen" eines Geräts beschrieben werden können? Das ist aktuell einfach alles irgendwie in die ETS Software reinprogrammiert?


Ich bin jetzt nicht sicher, ob deine Antwort die generelle Meinung der OpenKNX Community widerspiegelt, aber ich lese aktuell heraus, dass eine Offenheit nicht so gewünscht ist wie es "OpenKNX" suggerieren würde.

[abeggled]

Es ist relativ einfach, ohne ETS, wie sie heute daherkommt, closed Source und Windows, kein KNX.
Auch OpenKNX nutzt für die Produktdatenbankerstellung die ETS.
Alternativen gibt meiner bescheidenen Meinung nach nicht, es ist deshalb müssig alle paar Wochen/Monate darüber zu klagen, dass die ETS in unserem Fall ein paar Franken oder Euro kostet.
Das Forum als solches hat sonst eine gute Suchfunktion oben rechts.

[Techi]

VanCoding

Welche anderen Haus Automationssysteme wie KNX haben denn nun schon an die 30 Jahre auf dem Buckel und sind immer noch funktionsfähig und erweiterbar und kompatibel zueinander ? Das liegt sicher auch daran, dass es eine steuernde Instanz gibt die Wildwuchs im Zaum hält und über Regeln und Spezifikationen wacht.

Wenn ich mir die hochgelobte OpenSource Landschaft so anschaue, kann ich mir da nix vorstellen was auch nur annähernd die nächsten 6 Monate unverändert laufen könnte. Spätestens beim nächsten Sicherheitsupdate, was man ja faktisch machen muss weil so ziemlich alles im Netzwerk hängt, wird es schwierig.

Jedes mal wenn von einem OpenSource Projekt eine neue Version kompilieren will kann ich mir gleich 2 Tage Zeit für Anpassungen und Neuinstallationen reservieren, weil sich wieder mal alles geändert hat und nix mehr kompatibel zu vorher ist.
Na prost Mahlzeit, das wichtigste an Steuersystemen die bei mir im Gebäude zum Einsatz kommen ist Wartungsfreiheit, Beständigkeit und Kompatibilität im System.

Wenn mans richtig macht ist Software automatisch platformunabhängig, ganz ohne Aufwand. Das wurde bei ETS einfach verschlampt. Die richtige Lösung wäre wohl ohnehin ein Web-Basiertes UI, das immer erreichbar ist.

Es gibt viele Geräte, die kann ich ganz einfach per HTTP konfigurieren (z.B. Shellies). Da brauche ich keine proprietäre Software vom Hersteller, die auch noch Geld kostet und mir vorschreibt welches Betriebssystem ich nutzen muss.

Na da bin ich ja extrem froh, dass KNX primär keine IP Verbindung in jedem Gerät benötigt wo ich mich für den Rest der Nutzungszeit darum kümmern muss, dass alles sicher, UpToDate und funktionsfähig bleibt.
Wie ich immer sage, "ein Gebäude ist kein Smartphone"

Es ist doch jedem derzeit zu raten extrem umsichtig mit der Verwendung von IOT Geräte und allgemein mit der Verwendung von IP Verbindungen zu handeln. Was nicht unbedingt ins Netzwerk muss, sollte man auch nicht ins Netzwerk bringen.
Klar das widerspricht dem aktuellen Trend wo am besten wirklich alles is Netzwerk gehängt werden muss, aber gerade im/am Gebäude tut man sich und seinen Mitbewohnern auf Dauer keinen Gefallen.

[CaptainFuture]

Das ist technisch überhaupt kein Problem soetwas zu entwickeln. Wenn Du allerdings die ETS ersetzen willst, wirst Du ziemlich viel Ressourcen brauchen. Hier ist die Herausforderung eher das Marketing: Du brauchst viele Mitstreiter. Also Geld oder privates Engagement. Und die ETS ist zwar stellenweise richtig schlecht, funktioniert aber. Der Leidensdruck bei 90% der Anwender und 99% der Hersteller ist also nicht groß genug, Ressourcen in eine bessere Implementierung zu stecken.

[meti]

Hi 👋!

Konkret würde ich mir ein CLI wünschen, mit dem ich
- Geräte auflisten kann
- Geräte Adressen setzen kann
- Geräte-Funktionen und deren aktuelle Gruppen-Adresse auflisten kann
- Geräte-Funktionen eine neue Gruppen-Adresse zuordnen kann

Die ersten 3 Punkte sind eigentlich kein Problem. Das sollte jetzt schon mit verfügbaren Open Source tools machbar sein.
Der vierte Punkt ist schon etwas komplizierter, weil man dem Gerät ja erst mal sagen muss was seine Funktionen sind... also die Applikation bauen.

Einzig wo man drüber nachdenken könnte ist eine Verfügbarkeit auf anderer Basis als Windows. allerdings verliert man dann viel an Rückwärtskompatibilität von Geräten die da so manch exotisches Plugin benötigen

Knxa hat das ja auch schon mal gemacht - u d wieder verworfen - leider.
Soweit ich weiß gibt es keine neuen Geräte mehr, die ETS-Plugins benötigen. Bin aber nicht sicher seit wann das so ist. Ich sehe da auch kein großes Problem darin die bestehenden Plugin Geräte halt irgendwann nicht mehr zu unterstützen. Dann reihen sich die eben in die Liste "TP0, Datenschiene, PL, Serielle Schnittstellen, etc." ein 🤷 Wenn man 15 Jahre altes Zeug in einem neuen Projekt verbauen möchte, kann man ja immer noch ETS 6 dafür verwenden.
Niemand verlangt oder erwartet bei einer FOSS Neuentwicklung 100% Rückwärtskompatibilität für 30 Jahre alten Tand. Wenn die aktuell erhältlichen Geräte funktionieren - das wär ja schon mal was 😃

Wer soll sich dann bitte wieder in unterschiedlichste Programme einarbeiten? (...) Musst halt die Applikationsdatenbanken der Hersteller reverse entwickeln

Die zentralisierte Konfigurationsschicht ist imho das größte Manko an KNX. Geschuldet ist das bestimmt dem Alter und der damals verfügbaren Geräteresourcen. Aus heutiger Sicht wäre es wohl kein großes Problem mehr, dass jedes Gerät seine komplette Applikationsbeschreibung - inkl. Projektspezifischen Metadaten (GA-Namen zB.) vorhält. Dann könnte es auch eine Parallelentwicklung verschiedener Parametrisierungstools geben - und die wären auch untereinander austauschbar - wenn man die Applikation incl. Projektdaten aus den Geräten auslesen könnte... Dann gäbs halt auch den Zirkus mit Rekonstruktions-App und Projektdatei ja niemals verlieren nicht mehr. KNX-IoT hätte die Chance gehabt das mal umzusetzen 😬

Ordentliche öffentliche Dokumentation der Applikationsdatenbanken und Projektstrukturen wär schon mal ein erster Schritt in die richtige Richtung, aber nicht mal das gibts.

[thewhobox]

Die Konfiguration ist aktuell der Nachteil.

Die Konfiguration hat aber den enormen Vorteil einer zentralen Dokumentation.
Das wird von vielen einfach ignoriert oder als nicht wichtig erachtet, bis Sie mal von Nöten wäre.
Ich muss nicht zwischen 4 verschiedenen Anwendungen wechseln um Herstellerspezifische Sachen zu aktivieren (Dali ist hier ein negatives Beispiel leider oft).

Wäre das ganze offen, könnte eine Kompatibilität ganz einfach hergestellt werden

Die Kompatibilität kann nur vom Hersteller kommen und der hat alle notwendigen Unterlagen, macht es aber trotzdem nicht, da die Geräte alle noch funktionieren und Inbetrieb genommen werden können.

Das wurde bei ETS einfach verschlampt.

Schau dir mal den Marktanteil von Windows im Gründungsjahr von KNX an.
Welches Normale Unternehmen hätte da auf Mac gesetzt mit 3,5% oder gar auf Linux mit 0,34%.
Und das sind Zahlen für alle PCs also auch Private, deren Zielgruppe die ETS gar nicht ist.

Wenn die ETS einstellen wollen, können die das jederzeit tun. Alle gekauften Geräte werden dadurch quasi Briefbeschwerer, da nicht mehr ansteuerbar.

Der Vergleich hinkt etwas, aber ok.
Nur weil sie es nicht mehr verkaufen, verschwindet die ETS nicht von allen PCs... Die Geräte funktionieren weiterhin, da alles offline und dezentral.

Wenn es Alternativen gibt, heisst das nicht, dass ETS nicht wie bisher alle Geräte konfigurieren kann

Dann fängt es an wie bei Matter. In der Hersteller App gehen alle Funktionen und die Matter/KNX Applikation wird auf das nötigste reduziert, denn Updates kosten die Hersteller Geld. Warum also Updates für KNX machen, wenn es die eigene App besser kann?
Eine Software zur Inbetriebnahme hat viele Vorteile. Eben auch dass es die Hersteller in gewisser weise zwingt kompatibel zu sein.

eine Offenheit nicht so gewünscht ist wie es "OpenKNX" suggerieren würde.

Wir in OpenKNX haben uns gerade wegen den genannten Gründen oben dafür entschieden auf die ETS zu setzen.

Und ja ich weiß wovon ich rede.
Ich selbst habe einen Prototypen einer Alternative zur ETS gearbeitet und auch in bestimmten Rahmenbedingungen zum Laufen gebracht.
Aber viele unterschätzen einfach, wie kompliziert das Thema KNX ist, wenn man mehr als nur Gruppenadressen braucht.

Gruß Mike

[VanCoding]

Ich danke meine ursprüngliche Frage wurde damit ziemlich klar mit einem nein beantwortet. Danke.
KNX scheint dann wohl einfach nichts für mich zu sein.

Was für mich aber leider immernoch unklar ist:
In KNX gibt es so viel ich weiss ja kein Protokoll dafür, dass die Geräte sich selbst beschreiben können. D.h. die programmierende Software muss quasi alles über das zu programmierende Gerät wissen. Doch wie kommt ETS derzeit an dieses "Wissen" über die Geräte?

Senden die Komponenten-Hersteller eine Dokumentation an die ETS-Entwickler, welche das dann direkt in der Software implementieren? Oder macht da einfach jeder Hersteller irgendein Plugin für ETS, über das ETS dann an die Infos kommt? Oder gibt es doch irgendein Dateiformat, das die Hersteller für ETS generieren können und ETS dann einliest?

Irgendeinen Grund muss es ja geben, wieso es so schwer ist ohne ETS an die Gerätedaten ran zu kommen...

Das ist jetzt aber im Grunde Off-Topic.

Edit

Die ersten 3 Punkte sind eigentlich kein Problem. Das sollte jetzt schon mit verfügbaren Open Source tools machbar sein.
Der vierte Punkt ist schon etwas komplizierter, weil man dem Gerät ja erst mal sagen muss was seine Funktionen sind... also die Applikation bauen.

Super interessante aussage, danke. Bedeutet das, dass bei KNX Geräten die Logik und die Konfiguration nicht voneinander getrennt, sondern ein und das selbe ist? Wird da also, bei einer Änderung der Konfiguration gleich die ganze Software neu geflasht oder sowas? Das würde das ganze in der Tat etwas komplizierter machen.

Ich ging davon aus, die meisten Geräte hätten schon eine Software mit fixen Funktionen drauf, und man müsse denen nur noch die entsprechende Gruppenadresse zuordnen.

[BadSmiley]

Das ist ja nett. Dass du dich hier anmeldest, nur um uns, wenn auch etwas kompliziert, mitzuteilen, dass KNX nichts für dich ist.

Dafür wollte ich einfach mal Danke sagen.

[thewhobox]

Doch wie kommt ETS derzeit an dieses "Wissen" über die Geräte?

Das steht alles in der Produktdatenbank der Geräte.
Da kann jeder Hersteller Parameter und KOs definieren, die er eben braucht um das Gerät zu Parametrisieren.
Diese Datei importierst du in die ETS und somit weiß diese, was man alles einstellen kann und was für Verbindungen man zur Verfügung hat.

Plugins gibt es in neuen Geräten nicht mehr.
(DCA ist hier eine Ausnahme, das verwendet keine externe Datei als Anwendung, sondern läuft innerhalb der ETS)

Irgendeinen Grund muss es ja geben, wieso es so schwer ist ohne ETS an die Gerätedaten ran zu kommen...

Die Geräte an für sich sind Dumm und bekommen erst durch die ETS gesagt, was sie wie zu tun haben über die Parameter, die der Hersteller vorgibt.
Da Hersteller und ETS wissen, was die Daten machen und wofür sie sind, gibt es keine Notwendigkeit die Daten iwie noch Abfragen zu können.

Wenn du dich in die KNX-Spezifikation einarbeitest (die gibt es kostenlos für alle auf my.knx.org), dann kannst du mit ein paar HTTP Befehlen an die IP Schnittstelle die entsprechenden Tabellen auslesen und parsen.

Gruß Mike

[traxanos]

Das wurde bei ETS einfach verschlampt.

richtige Lösung wäre wohl ohnehin ein Web-Basiertes UI

Sag mir das du keine Ahnung hast, ohne das du mir sagst das du keine Ahnung hast.

Das ist "Schwachsinn" pur. Weist du überhaupt wie lange es KNX bzw. EIB schon gibt. Ich kann heute noch Gerät programmieren, da haben die Leute ihre Webseiten noch mit Frontpage zusammen geklickt. Da mit ActiveX und JavaApplet gearbeitet. Da konnte man nichts verschlafen, da gab es noch nichts anderes.

Ich bin selber Webentwickler seit über 20 Jahren, und da gab es soviel Inkompatibilitäten das wir Anwendungen in der zeit teilweise weit über 10 mal neu gebaut haben. Auch fertige Kaufprodukte mit Weboberflächen hab ich einige entsorgt, weil sie mit modernen Browsern nicht mehr bedienbar waren.

Alleine die verwendeten JavaScript-Frameworks die dauernd den Browser hinterher gepatcht werden mussten, um dann durch komplett neuere Frameworks ersetzt zu werden. Und der nächste kommt dann und beschwert sich das der Bus ja nur 9600 Baud hat und man das auch "einfach verschlampt".

[VanCoding]

Das ist ja nett. Dass du dich hier anmeldest, nur um uns, wenn auch etwas kompliziert, mitzuteilen, dass KNX nichts für dich ist.

Hä? 😅 Das es nichts für mich ist, bzw. immernoch nichts für mich ist habe ich ja erst durch die Antworten rausgefunden. Der Name "OpenKNX" hatte bei mir halt einfach die Hoffnung geweckt, dass KNX inzwischen nun vielleicht doch etwas für mich ist.

[VanCoding]

Auch fertige Kaufprodukte mit Weboberflächen hab ich einige entsorgt, weil sie mit modernen Browsern nicht mehr bedienbar waren.

Siehst du, wir reden doch vom selben. Auch du magst es nicht, wenn ein Gerät nur über die vom Hersteller vorgesehene Software (in deinem Fall das integrierte Web GUI) konfiguriert werden kann. Wäre die Schnittstelle offen gewesen, hätte man die Geräte weiterverwenden können, an der Schnittstelle ändert sich ja nichts. Mit etwas Glück hätte die Open Source Community sogar ein Alternatives GUI hervorbringen können.

Alleine die verwendeten JavaScript-Frameworks die dauernd den Browser hinterher gepatcht werden mussten, um dann durch komplett neuere Frameworks ersetzt zu werden. Und der nächste kommt dann und beschwert sich das der Bus ja nur 9600 Baud hat und man das auch "einfach verschlampt".

Ich gehe davon aus, dass auch an ETS einiges getan werden musste, damit es mit neueren Windows Versionen kompatibel bleibt. Software braucht nunmal Pflege, damit sie weiter lauffähig bleiben. Schnittstellen nicht. Deshalb ist für mich der "API-First" Ansatz ja eine Zwingende Voraussetzung für einen zukunftssicheren Betrieb. Brauche ich eine App vom Hersteller bin ich in der Regel raus.

[TabSel]

Die ETS is keine Software eines Herstellers.
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 die KNXA schon eine sehr sehr umfangreiche Software anbietet, und man mit sowas kein Geld verdient und die Konkurrenz unterstützen müsste. Das wird nix, siehe Matter z.B.

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