[Beantwortet] [V4.5] Universalobjekte - HowTo

[Hannatz]

Hallo zusammen,

ich habe nun endlich mal Zeit gefunden den TW2400 in der ETS zu konfigurieren, soweit erst mal alles ok. Hab mich am Handbuch entlang gehangelt, das meiste ist gut verständlich und nachvollziehbar, allerdings bin ich bei den "Universalobjekten" auf eine gedankliche Hürde gestoßen.

Ich hab gut 500 GAs in meinem Projekt, welchen Sinn macht es diese 1:1 mit den Universalobjekten (in einer abstrusen Klickwüste namens ETS) zu verbinden? Ich verstehe den Ansatz, hier ein KNX konformes Device hinstellen zu wollen, aber wo ist der Mehrwert? Wenn ich das ETS Projekt importiere habe ich doch auch alle GAs in TW drin, warum muß ich diese dann noch mal mit den Universalobjekten verknüpfen? Leider habe ich auch in der Suche nichts dazu finden können, an der Stelle kam ehrlich gesagt etwas Frust auf da ich den Eindruck hatte, hier die Usability einem funktionalen Overkill geopfert zu haben. Vielleicht bin ich auch zu doof dafür, mit meinem eigenen ETS-Projekt komm ich klar und hab auch einiges im WG an Logiken implementiert, würde mich daher schon als versierten Enduser (aber kein SI oder Developer) bezeichnen. Vielleicht kann den Mehrwert auch jemand in etwas einfacherer Sprache bzw. konkreten Anwendungsfällen erläutern, leider ist mir das auch nach 3maligen Lesen des Absatzes in der Doku nicht klar was der Mehrwert dahinter ist. Wenn das Produkt Erfolg habe soll sind solche Hürden sicherlich ein Hindernis, es ist nicht jeder ein absoluter ETS Virtuose.

Wenn es für die Benutzung zwingend erforderlich ist, warum gibt es dann keinen Importer für den Basisimport? Ich habe gesehen, dass einige hier an sowas basteln, leider wohl noch alles WIP.

So, bitte jetzt nicht gleich steinigen, ich habe einfach mal versucht meine aktuellen Fragen in Worte zu fassen ohne jemanden angehen zu wollen.

Gruß Hannatz

[gbglace]

Der Server hat bestimmt auch einen Softwarestand den Du uns noch mitteilen möchtest im Betreff des Beitrages.


kleiner Spoiler:

es gibt die ETS App für die Massenanlage von KNX-Objekten.
für alles andere der "Schimpferei" gibt es auch sehr sinnvolle Erklärungen.

Wenn ein Server nur mit dem Import der Projektdatei funktioniert. Dann haben die alle keine nativen KNX-Objekte sondern alle nur mehr oder weniger gut implementierte Simulationen der Fähigkeiten eines KNX-KO.

Und bei all den Servern führt diese Nutzung zu der irrigen Annahme man schreibt etwas bei der Kommunikation mit dem KNX-Bus in/auf/an eine GA. Das ist alles immer falsch. Die GA ist das was mit dem Telegramm auf dem Bus gesendet wird. Senden tun die KO und empfangen tun die auch. Und das tun die so wie es in den Flags in der ETS definiert ist.

All die anderen Systeme sind dann einfach nur Lauscher auf dem Bus und fischen sich da was raus. Die Eigenschaften der Flags werden nur bedingt sauber und ordentlich umgesetzt.

Der TWs benutzt die Projektdatei nur Ergänzungen von Metadaten die in den Telegrammen selbst nicht enthalten sind um Dir im Buslog nicht nur den Hex-Wert des Values anzuzeigen sondern eine ordentliche Zahl mit passender Einheit und einen Namen neben der PA vom Absender.

Die Fähigkeit des TWS selbst Telegramme zu senden oder zu empfangen und ie Werte im Objektsystem verfügbar zu machen setzen ein effektives KNX-KO voraus.

Beim X1 hast auch solche effektiven KNX-KO aber auch nur so pseudo synthetisierte. Dieser wilde Mix ist natürlich noch viel schlimmer und führt auch regelmäßig zu Verwirrungen bei den usern.

Und beim HA darf man sich alle KNX-Elemente in eigenartigen Entitäten in einem YAML zusammenbauen. Auch alles mehr als unkomfortabel, weil man da immer gleich versucht irgendwie ein echtes Gerät zu jeder GA zu definieren, was bei manchen GAs einfach keinen Sinn ergibt. HA ist da eben nicht am KNX ausgerichtet entstanden.

Und weiterer Punkt für echte KOs zur Kommunikation. Man hat automatisch jene GAs am Server verbunden mit denen er wirklich arbeiten soll. und nur jene muss man auch anlegen. und man hat bei mehreren Linien damit auch automatisch saubere Filtertabellen und wundert sich nicht warum da einiges fehlt oder man sich Dummy-Applikationen ins Projekt anlegt damit der Server auf der anderen Linie auch davon etwas mitbekommt.
Damit haben andere user ebenso diese Art Klickerei sich GAs an Dummy Applikationen zu verbinden. nur beim TWS hast dazu sogar ne App wo es auch ein file import sein kann.

[Hannatz]

Hallo @gbglace ,

Danke für Deine Rückmeldung. Kurz die Basics (hatte ich leider übersehen), ich hab afaik die ETS 5.7.7, der TW läuft auf 4.5. Beides also die jeweils aktuellen Main Releases.

So, inhaltlich ist „Schimpferei“ vielleicht etwas übertrieben, Frust trifft es wohl eher.

Ich weiß nicht ob wir uns richtig verstehen, ich möchte in der ETS keine neuen GAs anlegen sondern will die Universalobjekte gemäß Doku mit den bestehenden GAs in der ETS verknüpfen. Diese ist da sehr strikt und erweckt zumindest bei mir den Eindruck, dass diese Vorgehensweise alternativlos sei.

Den Rest der Erläuterungen hab ich grundlegend verstanden und das mag technisch alles super duper sein, aber meine Frage bleibt bestehen: was ist der konkrete UseCase dafür? Wo reicht der normale Import der GAs per ETS-Projekt nicht aus?

Im Wiregate hab ich die GAs auch importiert bzw. manuell angelegt, damit konnte ich alle meine Anwendungsfälle umsetzen. Sicher bin ich bzgl. der Besonderheiten der Flags eher Anfänger, aber 90% der restlichen potentiellen Kunden des TW dürften noch weniger davon verstehen als ich.

Ich will den TW in keinster Weise schlecht machen, ich versuche nur den Neudeutsch „Business Value“ dahinter zu verstehen.

Hoffe meine Intention ist nun etwas deutlicher…

[AndererStefan]

Hi,

naja, wo ist der UseCase...? Das ist halt wie KNX funktioniert. Es gibt auf Geräteseite Kommunikationsobjekte (Anschlüsse) und Gruppenadressen (Nachrichten) und man muss nunmal definieren was worauf wie reagieren soll. Jeder KNX-Taster und jeder KNX-Sensor funktioniert nach diesem Prinzip. Als natives KNX-Gerät funktioniert der TWS daher auch so.

Es gibt andere Methoden "einfach auf dem BUS mitzulauschen" auf Signale zu reagieren oder diese zu senden (z.B. Node-Red bzw. KNX Ultimate, HomeAssistant), aber das ist nicht, wie der KNX-Standard das vorsieht. Das Problem ist, der ETS sind die Geräte dann unbekannt und auf dem BUS sind diese quasi nicht identifizierbar weil sie keine PA haben sondern über irgend ein IP-Interface senden. Als Workaround legt man dann Dummy-Geräte an und verknüft die GA dort an Dummy-KO, damit zumindest die ETS Kenntnis darüber hat.

Ja, es könnte beim TWS mit Sicherheit auch einfacher gehen, aber das hat halt bisher noch niemand entwickelt. Irgendwo wird man immer definieren müssen, was man eigentlich steuern/verbinden möchte.

Mich hat bei dem Prozedere am meisten genervt, dass man in der ETS für die Kommunikationsobjekte im Dropdown-Menü die passenden DPT zu den GA auswählen muss und aber auch auf konsistente Datentypen in den Eigenschaften der GA und der KO achten muss. Da passierten mir laufend Fehler. Dass die ETS so zäh ist, macht es nicht angenehmer.

Daher habe ich mir ein Excel-Tool erstellt das eine *.csv-Datei vorbereitet, die man dann mit dem WireGate\Timerwolf Importer einlesen kann: viewtopic.php?p=61896#p61896


VG
Stefan

[Hannatz]

Hi @AndererStefan,

danke für den Link, schaue ich mir die Tage in Ruhe an.

Das mit dem „so funktioniert KNX nun mal“ finde ich zu kurz gesprungen, im Wiregate musste das ja auch nicht gemacht werden und trotzdem konnte ich damit ne Menge machen. Als PA war das bei mir dann die 1.256, klar identifizierbar.

Aktuell hat der TW in der ETS genau zwei GAs zugewiesen bekommen: Zeit und Datum

Warum also beim Wechsel auf den TW diese Änderung, was ist der Mehrwert zum Handling wie beim WG? Nur um nen KNX Aufkleber drauf zu pappen? Sorry wenn ich das einfach noch nicht blicke…

[gbglace]

Das wiregate war an der Stelle auch weg vom KNX Standard und hat da auch nur auf dem gelauscht, was an der Linie wo es dran steckte an Telegrammen vorbei kam. Mit dem knxd einen KNX-IP Router simulieren war technisch möglich ist aber vom Standard auch nicht vorgesehen.
und in dem Logikcodes hast dann immer GAs referenziert. Aber das ist eben nicht wie ein KNX-Gerät funktioniert.

Einige machen es anders aber im HA und KNX funktioniert auch erstmal gar nichts wenn Du die ETS Projektdatei einliest. Die Systeme können Dir dann wie im TWS einfach nur einen sprechenden Bus-Log erzeugen.

Wenn Du mit dem HA etwas mit KNX-Objekten machen willst musst Dir auch erst Entitäten erzeugen und das ist mit dem YAML Zeug auch ein wildes Gefrickel. Und im NR musst auch erst Mappings bauen.

Und gedanklich ist es eben eh fraglich GAs als Objekte zu interpretieren und darauf Schreib / Lese / Antwort / Reaktion auf Antwort-Transaktionen zu definieren.

Die anderen Systeme scheine da nur komfortabler, sie sind es aber nicht weil sie am Ende eben immer ein falsches Verständnis zum KNX beim DAU user etablieren. Kann man machen kommst dann halt nur Murks bei raus, wenn es doch mal aufwändiger wird.

Und wenn man es ordentlich anstellt mit dem Gedanken es sind echte KOs dann kann man eben auch KOs sparen, da man dann eben besser darüber nachdenkt was soll der TWS selbst tun also wo ist er Taster wo ist er Aktor und dann merkt man ach ja da kann ich ja auch einfach 5 GAs an ein KO packen und muss nicht 5 KO's definieren und erst noch ne ODER Logik bauen oder 5 KNX-Objekte "speicherhungrig" an ein Anzeigeelement der Visu verbinden oder an ein MQTT Ausgangstrigger.

Die Leute vom OneHome Server streben es an mit einem Projektfile import automatisch alle KNX-Datenpunkte intern anzulegen damit man damit im Innern dann arbeiten kann. aber damit das funktioniert muss man wieder das ganze ETS Projekt entlang derer Strukturdefinitionen anlegen damit das funktioniert.

Die ETS ist halt noch fernab über alle Geräte sauber mit virtuellen Geräten zu arbeiten die auch über Aktoren/ Taster verteilt Ihr Repräsentanz haben. Das mit den Funktionen ist ein Versuch aber auch noch reichlich umständlich.


Der KNX selbst in der Konfiguration ist eben einfach kein System was für jedes Daddel Handy wischi waschi Kind geeignet ist. Insofern muss man sich wenn man es richtig nutzen will auch mal mit den Eigenheiten des Busses beschäftigen oder wen engagieren.

Bis die ETS und der KNX drag and drop für Handynutzer funktioniert werden noch einige viele Jahre vergehen.

Du musst nur nach der Importer App schauen dann sind Deine Sorgen schon alle beseitigt.

[Hannatz]

Hi @gbglace,

so langsam nähern wir uns, danke für deine Geduld.

Wie das andere Systeme machen ist egal, bleiben wir doch beim TW vs WG. Wie Du richtig beschreibst, das WG hat keine echten GAs genutzt. Was ist aber der Nachteil dieser „Emulation“ anstatt Verwendung nativer GAs?

Ein „KNX funktioniert nun mal so“ wäre mir da zu kurz gesprungen, wenn eine Vorgehensweise funktioniert ist es erst mal nicht dumm. In den ersten Teslas waren Laptop Batterien, auf den ersten Blick irre aber die fuhren auch passabel…

[gbglace]

Naja dann hätte man den TWS in seiner KNX Funktionalität Zwei- oder Dreiteilen müssen.

Ein Teil mit Applikation um als Interface funktionieren zu können. (das wiregate hatte nicht mal das, daher auch kein Chance ein zertifiziertes Gerät zu werden)
Ein Teil mit Applikation um ggf KOs wie Zeitserver, keep alive des TWS selbst zur Verfügung zu stellen in dem Sinne, wie andere am Marktteilnehmer KNX-Interfaces/Router es anbieten.
Ein Teil der KNX Daten für TWS interne Logiken und Visu bereitstellt.

Die ersten beiden Teile währen quasi analog zur bisherigen KNX Funktionalität. der andere wäre ein weiteres Objektsystem im TWs was KNX heißen würde aber dann nicht mehr KNX-KO orientiert sondern rein KNX-GA orientiert ist.

Und da muss ich sagen denke ich auch anders die ständige vollständige Konzentration auf GAs ist eigentlich genau das was mich bei all den anderen Geräten und Systemen stört. denn mit dieser gedanklichen Konzentration auf GAs wird man auch niemals in der Lage sein so einfach wie matter usw. zu funktionieren in der Einrichtung. Eine GA ist kein Objekt im KNX und hat daher auch keine Eigenschaften der Gebäudestruktur und nicht der Gewerkestruktur. Insofern benötigt man immer eine weitere Mapping ebene.

In der ETS fehlt ebenfalls eine solche Ebene, aber die wird in der ETS auch nur auf Basis vom mapping von KO's erfolgen. denn wenn das richtig funktioniert wird die ETS von allein irgendwelche virtuellen Drähte zwischen den KO#s spannen (die GA) und dann wenn die ETS das kann dann geht KNX so einfach wie Handy-Wisch Geräte wie bei matter in betreib zu nehmen. Wenn aber all die Visu Server hart nach solchen GA zahlen suchen und das innere KNX Objektsystem aufbauen. muss man nochmal zusätzlich alles nochmal bauen reverse was die ETS da tut.

Aktuell definierst den TWs mal als teilnehmenden Aktor mal als teilnehmenden Taster und stellst dann in der ETS die KO#s zur Verfügung die dann wieder von der ETS automatisch verbunden werden können.

Will einer mehr in TWS Oberfläche als in der ETS sich sowas zusammenbasteln, dann gibt es da auch Gedanken quasi die KNX Stack Programmierung reverse zu machen. Der TWS programmiert sich ja quasi eh schon selbst wenn man da mit der ETS auf programmieren klickt. Dann kann man mit einer ETS-App auch nachdem man sich die "KNX-Welt" im TWS Ui gebaut hat den KNX Stack programmiert hat, auch das ETS Projekt aus dem TWS heraus updaten (bezogen auf das Gerät TWS, nicht die sonstigen KNX Geräte im Projekt). Aber das sind alles gerade so Gedankengänge für zukünftige Entwicklungen. Aber aktuell geht es eben nur in die Richtung von der ETS an den TWS und da ergibt eben nur die KO-zentrierte Sicht Sinn keine GA-zentrierte Sicht. Anders ist der TWS in der gesamten Applikation auch nicht zertifizierungsfähig.