ElabNET Technik Forum

Verehrte Nutzer des TImberwolf Servers und alle die es noch werden wollen,

Von unserer Seite ist zeitnah geplant:

1. Schnellstmögliche Registrierung der bestehenden Applikation

2. Erweiterung der Applikation um weitere DPT (zunächst die bislang diskutierten / gewünschten DPT mit einem Wert im Telegramm)

3. Anpassung der Applikation, dass künftig auch die IP-Adresse des Servers darüber programmiert werden kann (vermindert Support)

4. Erweiterung der Applikation auf die vollen 8.000 Objekte (sofern die Toolchain aus Manufacturer Tool und ETS nun mitspielt....)

(Falls die Schritte 1-3 einzeln / getrennt realisiert werden müssen, um 1. z so zeitnah wie möglich zu erfüllen, dann wird für nachfolgende Schritte pro Veröffentlichung jeweils eine erneute Registrierung ggfls. auch neue Zertifizierung - je nach Geschmack der KNXA - notwendig werden)


Von unserer Seite ist mittelfristig geplant:

5. Erweiterung der Applikation um DPT mit mehreren Werten in einem Telegramm (hier müssen wir erst den Dispatcher / Subsysteme dafür fit machen, dass es "Complex-Objekte" gibt, also mehrere Werte in einem Objekt gespeichert sind. Das ist nicht trivial, macht auch viele Logikelemnte zur Aufteilung / Berechnung / Manipulation / Mixer usw. notwendig. Darum separat.

6. Erweiterung der Applikation und des Servers um eine massiv vereinfachte Programmierung von Objekten und GA Zuordnung. Was wir genau vorhaben ist ein Geheimnis.


Um sicherzugehen, dass wir alles berücksichtigt haben, daher nun die Frage an Euch:


Welche Wünsche habt Ihr - darüber hinaus - an die Applikation in der ETS?

Ergänzend zu Euren Wünschen hier unsere Fragen

A. Einteilung der Objekte in Gruppen. Heute haben wir in der ersten Stufe ("Kanäle") hunderter Blöcke und dann pro Seite nochmals 10 Objekte zum Freischalten

Wenn wir die ETS Toolchain dazu bekommen, alle 8.000 Objekte zu unterstützen, dann sind das 80 Kanäle zu je hundert Blöcke. Das ist dann eine lange Liste in der ETS.

Unser Gedanke hier ist, dass man jeden Kanal zuerst freischaltet und diesen dann auch gleich benennt, so dass es hier zu einem sinnvollen Namen kommt. Das hat den Vorteil, dass jemand, der Anfangs nur 100 Objekte braucht, dann eben auch nur den einen Kanal sieht und nicht 79 unbenutzte Kanäle, weil das mindert die "Scrollerei" in der ETS im linken Fenster.

Oder wollt Ihr eine andere Aufteilung? Bei uns in der Diskussion waren auch 250er Blöcke (pro Kanal) mit zehn Seiten zu je 25 freischaltbaren Objekten (womit die Seite besser ausgenutzt wird).

B. Sollte der KNX Objekt Manager im TWS diese Kanalstruktur ebenfalls reflektieren, so dass man eine Hauptunterteilung nach diesen Kanälen (100er oder 250er oder .... Blöcke)) für Eure Ordnung?

Und Eure Wünsche natürlich


Disclaimer: Das hier ist nicht laut gedacht, sondern tatsächliches Vorhaben, das DERZEIT bereits in der Umsetzung ist. Trotzdem kann ich keine Termine nennen, aber Punkt 1 "brennt sakrisch".


lg

Stefan

Hi,

ich freue mich drauf - das klingt ja alles sehr gut!
Besonders Punkt 6 finde ich spannend

Zu deiner Frage:

A)
Ich nutze das ETS-Fenster meist horizontal halbiert (oben Gebäudestruktur/Geräte; unten GA). Da passt für meine Zwecke die Liste mit 10 Objekten gut auf den Bildschirm.
Dezimale Schritte finde ich zudem augenfreundlicher als „krumme“ Blöcke von z.B. 25.

B)
Ich bin mit der scrollbaren Liste im Status Quo zufrieden. Eine hierarchische Blocking fände ich nicht so schön. Was ich mir noch vorstellen könnte, wäre eine mehrseitige Liste mit Blätterfunktion wobei man die Anzahl der Zeilen pro Seite aber einstellen kann. - Wie im Busmonitor.

Viele Grüße
Stefan

Nur mal laut gedacht
Wenn’s diese Auswahlmöglichkeit in der Applikation gäbe (Auswahl der Blöcke 10 25 50 100 250 mit dementsprechender Unterteilung )
Würden sich vermutlich nicht nur die freuen die für das eine stimmen,
sondern auch die anderen die für das andere gestimmt hätten

Ist hald nur die Frage ob dies in der Ets möglich ist und was ihr wollt ergo elabnet

Kostet hald alles was

Hi Georg,

die Applikation in der ETS ist nicht frei programmierbar, sondern man stellt mit dem Manufacturer Tool ein, welche Kanäle, Parameter und Kommunikationsobjekte es gibt und die Abhängigkeiten der KO von den Parametereinstellungen.

Ob man in der Applikation dem Nutzer eine Wahl lassen kann, wieviele Kanäle es mit welcher Unterteilung gibt?

Werden wir sehen

lg

Stefan

dynamische Strukturen kennt die ETS so nicht, es ist alles schon einmal vordefiniert an Struktur und man hat dann quasi nur unterschiedliche Sichtbarkeiten. Das ist auch immer ein Thema in den großen Open-KNX Applikationen wo man sich noch dynamischere Elemente als Interaktion wünschen würde.

Wenn man die Kanäle dann bezeichnen kann wären da eher kleinere als größere Blöcke interessant, um dann eben darüber sich die "virtuellen Geräte" mit Ihren KOs definieren / Clustern zu können.

Individuelle Namen der KOs würde da zwar eher zum Prinzip TWS passen aber das sieht die ETS glaube auch nicht vor, das hat es nur auf der Kanalebene.

Hi Göran,

gbglace hat geschrieben: ↑Do Apr 17, 2025 2:05 pmWenn man die Kanäle dann bezeichnen kann ...

Kann man übrigens heute schon in der ETS, wissen wohl nur wenige, daher wollen wir einen Menüpunkt dafür machen.

Heute geht das über den Eigenschaftendialog:




Just zur Info

lg

Stefan

Ahh sehr gut. bisher hab ich das immer direkt als Erfassbox in den Applikationen gesucht und erwartet. gut zu wissen.

Hallo Stefan,

habe an deinem Vorschlag oben nichts zu ergänzen. Wenn das alles so nach und nach kommt, ist das super!

Wieder was gelernt (bez. Bezeichnung).

Für mich ist beschriebene Vorgehen auch perfekt, wobei ich die Notwendigkeit von 6) weniger sehe.
Für die Erstanlage der Objekte bietet sich aufgrund der Übersicht und Menge eine Vorbereitung in Excel inkl. Importer App einfach an.
Spätere Ergänzungen um einzelne Objekte sind heute schon kein echtes Problem, wenn die ETS dann noch performt schon gar nicht.
Das anders zu lösen ist halt wieder ein Feature, das viel Geld kostet und für den (End-)Nutzer nicht sichtbar ist. Just my 5ct.
Lg
Robert

StefanW hat geschrieben: ↑Do Apr 17, 2025 12:45 pm die Applikation in der ETS ist nicht frei programmierbar, sondern man stellt mit dem Manufacturer Tool [...]

Ob man in der Applikation [...]?

Werden wir sehen

you nailed it.

Dieses GUI-zentrische Entwickeln für derart komplexe Dinge ist nicht zielführend. Es muss als erstes eine API her. Das ermächtigt jeden Menschen/jedes Tool, GUI, WEB und eigene Software zu erstellen.

Für Gruppenadressen habe ich mir z.B. in einem Tag Arbeit für die Ewigkeit einen Generator gebaut beziehungsweise bauen lassen (dank LLM): link (KNX-Forum)
Hätte die ETS keine Importfunktion: fail.
Was wäre besser: eine API zum Importieren / GA pflegen und man könnte GA-Generatoren bspw. direkt anbinden. (Ganz abgesehen davon, dass die GAs Lösung grundsätzlich mal überdacht werden muss (Thema fehlende Semantik)).

Alle Such- und Ersetzfunktionen in der ETS für GAs sind imho verschwendete Lizenzkosten, da es eine nicht nachhaltige Lösung und fehleranfällige Pflege ist.

Zurück zum Thema: Warum den Restriktionen (und Kosten) der KNXA unterwerfen. Ich würde alles was geht außerhalb der ETS lösen. Wie gesagt, Schritt 1 ist die API. Eine GUI ist eine letzte Notlösung, da sie nicht automatisierbar ist. Ja, sie muss von mir aus sein, da viele (noch) keine Automatisierungen erstellen können. Aber 1. wird diese Aufgabe in den nächsten 5 Jahren für jeden durch Umgangssprache bedienbare Software durchführbar sein und 2. braucht diese mit Umgangssprache bedienbare Software Schnittstellen (APIs) und 3. kann die Basis für die GUI ebenfalls eine API sein und schon sind alle Pfade beschreitbar.

sorry fürs Abschweifen, bin heute ein bisschen

Zurück zur Lösung: eine Applikation, die einen Import (DCA / Konfigurationsupload wie bei den Open KNX Geräten (link 1/ ...)
ermöglicht und weit von der ETS weg, wenn es um die Generierung der Konfigurationsdaten geht.

@jhaeberle hat das hier auch schon mal schön skizziert.

Ob das alles in der ETS abbilbar ist / Registrierbar ist (?) Ich hoffe ja.


Gruß

Franky