ElabNET Technik Forum

Hi @gbglace ,

mit "Wiregate-GAs" meinte ich diverse GAs, welche ich nur dort und nicht zwingend in der ETS benötigt habe. Ein paar Temp.-Fühler und ein paar Sachen im Logikprozessor. Das meiste war aber eh in der ETS drin, nun eben halt komplett und sauber mit DPT gepflegt. Migration ist ja auch immer ein wenig vorher aufräumen...

Mein Vorschlag im Sinne nach vorne gucken wäre folgender: in der Doku ist der Aspekt nicht berücksichtigt, ich würde daher vorschlagen das zu ergänzen. Also das die GAs nur für den Busmonitor und Grafana genutzt werden können, alles weitere incl. Visu und Logiken jedoch als Universalobjekte gemappt werden muß. Genau diesen beiden Punkte sind nämlich anders als beim Wiregate, das war mir so nicht klar und habe ich erst (und vor allem) Deiner Unterstützung gelernt. Die Doku ist deswegen nicht falsch, bitte nicht mißverstehen!

Ansonste werde ich mich noch mal auf die Suche nach einer Best Practice bzgl. der "Universalobjekte in der ETS anlegen", das dürfte ja alle TWS User betreffen/betroffen haben.

Gruß Hannatz

Hi,

das einzige, was mir als relevanter Tipp für die massenhafte Erstellung von Universalobjekten einfiele, wäre diese mit Blick auf eine mögliche Weiterentwicklung vorsorglich in 100er Blöcken nach DPT-Klasse zu gruppieren:

Die ETS wird bei Applikationen mit vielen Objekte langsam (obwohl der Standard dies vorsieht) und Elabnet hat sich einen Trick überlegt um die Performance bei einer großen Anzahl von KO zu verbessern. Siehe dazu diesen sehr informativen Post:
viewtopic.php?t=5602&start=90#p63245

Ob das so kommt, oder ob die KNXA einen Weg findet die ETS zu beschleunigen, weiß ich nicht. Nötig soll eine Gruppierung jedenfalls nicht sein, schlimmstenfalls profitiert man nicht von der möglichen Geschwindigkeitssteigerung der ersten 2000 KO. Die gesamten 8000 KO gehen erst mit der neuen Applikation.

Ansonsten ist eine Struktur nur persönlicher Geschmack, bzw. Ordnungsdrang. Man kann im TWS überall nach den Beschreibungen der GA suchen, ist es nicht nötig eine Struktur bei den KO zu haben.

VG
Stefan

@Hannatz

Wenn Du umziehst lösche auch gleich diese internen GAs alle weg. Denn der TWS kann ganz ohne KNX Bus die 1-wire Werte
In der Logik und Visu verwenden.

Es muss wirklich nur das als KO angelegt werden was auch ein anderes KNX Gerät benötigt und darüber verschickt werden soll.

Hallo Hannatz,

Hannatz hat geschrieben: ↑Di Dez 09, 2025 4:40 pmMein Vorschlag im Sinne nach vorne gucken wäre folgender: in der Doku ist der Aspekt nicht berücksichtigt, ich würde daher vorschlagen das zu ergänzen. Also das die GAs nur für den Busmonitor und Grafana genutzt werden können, alles weitere incl. Visu und Logiken jedoch als Universalobjekte gemappt werden muß.

Das steht so alles in der Doku (im Wiki). Ich habe mir das extra nochmal angesehen.

Ich kann nicht dort schreiben "Übrigens, die GAs können nur für den Busmonitor und Grafana genutzt werden", weil der Sachverhalt so nicht beschrieben werden kann.

Der Timberwolf Server hat hinsichtlich KNX mehrere Funktionen. Das ist der Stack mit bis zu 8.000 Objekten (derzeit 2000 nutzbar wg. ETS) und das ist das Logging und das ist das IP Tunneling. Diese Funktionen sind erklärt.

Beim Logging wird der gesamte Busverkehr aufgezeichnet. also auch die PA-zu-PA-Kommunikation und eben auch die PA-GA-Kommunikation. Es werden keine "GA" genutzt oder lesend drauf zugegriffen. Es ist einfach nur ein Log in einer Zeitseriendatenbank auf die mit einem SQL ähnlichen Dialekt zugegriffen werden kann, was man z.B. aus Grafana nutzen kann, zumal dies vorinstalliert ist.

Es steht an mehreren Stellen, dass der Timberwolf Server ein KNX Gerät ist, dass aus der ETS programmiert werden muss. Es gibt im Wiki auch ein hervorragendes Video das dies zeigt. Zudem gibt es eine Erläuterung, dass die Kernfunktionen eine Programmierung der Universalobjekte durch die ETS benötigen und warum das so ist.

Hier in diesem Absatz https://elabnet.atlassian.net/wiki/spac ... jektimport wird extra erklärt. dass der TWS NICHT SO wie andere Geräte auf dem Markt nur auf Basis eines Projektimportes arbeitet, sondern hier eine Programmierung von KNX Objekten erforderlich ist (und es steht dort auch ausgiebig, warum wir das so entwickelt haben).


Lieber Hannatz, ich vermute, Du hast so sehr erwartet, dass es beim Timberwolf Server so wie beim WireGate Server sein muss und hast alle anderen Darstellungen in der Doku deshalb versehentlich überlesen. Das kann durch einen "BIAS" kommen, also eine Voreingenommenheit.

Es ist schwierig beim Schreiben einer Doku daran zu denken, auf welche möglichen BIAS beim Leser diese Doku treffen wird und welche Klarstellungen deshalb nötig sind und an welcher Stelle und wie oft im Text. Eigentlich befinden sich im Text bereits mehrere solcher Klarstellungen. Mehr kann man natürlich immer wünschen, aber wo endet das?

Ich werde bei der nächsten Überarbeitung zusehen, dass ich den "direkt mit GA kommunizieren" BIAS durch weitere eingeschobene Klarstellungen besser adressiere.

lg

Stefan