bin heute von OPC auf XML umgestiegen, da dann die Datentypen/Variablen-Art besser übernommen wird. Jetzt habe ich jede Menge doppelte Einträge, diese sortiere ich einfach mal aus…
Aber jetzt zur Frage, beim Import (egal ob OPC oder XML) wird wir immer pro Variable ein „Unterordner bzw. Instanz“ erzeugt. z.B. „KNX Variablenname“ ist der Ordner/Instanz, darunter liegt dann „value“ mit dem entsprechenden Wert. Bisher habe ich „Value“ wie den Ordner/Instanz übergeordnet umbenannt. Kann ich das beim Import gleich „richtig“ machen?
Sonst wird in der Visu auch immer viel Platz verschwendet…
Wieso wird in der Visu Platz verwendet, wenn der Name anders ist?
Die Visu baut man idr. auch aus Links zusammen.
Ich persönlich gebe dem Link einen passenden Namen. Man kann aber auch per Script z.B. alle ‚Value‘ auf den Namen der übergeordneten Instanz umbenennen.
Vom Parent der Variable, welche den Ident „Value“ hat. Die heißt dann so wie die zugehörige Gruppenadresse, also beispielsweise LD.Wohnzimmer-Wandlampe.E/A.
In dem Fall kommt nur der Part nach dem - und vor dem . zum Einsatz für die Namensgebung.
Ich sehe für mich persönlich keinen Grund, die Werte-Variable umzubenennen. In 14 Jahren IP-Symcon nicht. Aber es gilt wie immer: Es gibt kein richtig und kein falsch.
Natürlich hat der Parent den richtigen Namen der GA, aber in meinen bisherigen Visu-Ansätzen war der Parent wenig hilfreich, weil das ein unschöne/unübersichtliche Schachtelstruktur im Webfront erzeugt. Ich baue meine Visu-Struktur immer mit Dummys und verlinke dort die Variablen, nicht deren Parent. Und dann ist es halt unpraktisch wenn die Variable (und der daraus abgeleitete Webfront-Link) überall „Value“ heisst und manuell umbenannt werden muss.
Das ist richtig, die einzig sinnvolle Variante und auch das empfohlene Vorgehen des Herstellers.
Ich mache es so:
Nehmen wir an, die Instanzen sind innerhalb der Struktur richtig abgelegt und es existiert bereits eine Struktur aus Kategorien und Dummys für das WebFront. Ich habe ein Skript. In dieses Skript kopiere ich die ID des Dummys, in welchem die Links erstellt werden sollen. Dann markiere ich alle Instanzen, dessen Value-Variable verlinkt werden soll und kopiere die IDs ebenfalls in mein Skript und „schwupp“ erstellt dieses Skript die Links und benennt die Links auch gleichzeitig richtig, indem es von LD.Wohnzimmer-Wandlampe.E/A nur „Wandlampe“ verwendet.
Es wäre zu viel Arbeit, 10 Instanzen aufzuklappen, damit die Value-Variable sichtbar wird, diese dann zu markieren, zu verlinken und umzubenennen. Daher kopiere ich nur die ID des Ziel-Dummys und die IDs der Instanzen, dessen Value-Variablen verlinkt werden sollen - fertig. Man kann sagen, ich sehe die Value-Variablen eigentlich nie.
Ich will meinen Kunden ja nicht 20 Stunden IP-Symcon Einrichtung in Rechnung stellen. Daher wird das alles per Skript halbautomatisch erledigt.
OK Christoph, Danke für die Erklärung deines Workflows!
Letztlich scheinen wir uns einig zu sein, daß man den Namen des Parents übernehmen möchte, ggf mit leichten Anpassungen. Wir haben dazu zwei Vorgehensweisen, die doch recht ähnlich sind:
Umbenennen der Variable per Script (Post von Tobias) und der Link übernimmt automatisch diesen Namen
Variablenname bleibt unangetastet, stattdessen Umbenennen des Links in deinem Script
Beides führt mit vergleichbarem Aufwand zum gleichen Ziel. In meinen Webfronts sind die KNX-Instanzen teilweise mehrfach verlinkt (Seitengliederung nach Funktion, zusätzlich Seitengliederung nach Raum) und da erschien es mir sinnvoll den Namen einmalig direkt an der Quelle (=Variable) zu setzen anstatt in jedem Link.
Übrigens vermute ich, dass wir hier langfristig seitens der ETS mit dem Semantic Export, der mit der 6.1.1 kommt und Richtung 6.2 noch besser wird und mit den dazu kommenden Funktionsbausteinen eine schönere Lösung direkt von der ETS bekommen werden. Dann wird es echte „Geräte“ Instanzen in IP-Symcon geben, die automatisch mehrere Variablen haben und für die dann auch die Kacheln gleich passen werden. Das ist aktuell noch alles in Entwicklung, aber das nächste Jahr wird was das Thema angeht und sofern die KNX Integratoren auch wollen, echt spannend und einen echten Mehrwert bieten (meiner Meinung nach).
Ich werde dazu hoffentlich Richtung Jahresende in einem Webinar (oder spätestens auf dem Event im Januar) ein wenig Sneak-Peaks liefern
(Nicht von den kuriosen Namen/der sinnlosen Gebäudestruktur irritieren lassen - wichtig ist, dass es mehrere GAs gibt, welche einer klaren Funktion zugehörig sind. Und dadurch lassen sich auch einfacher die Status GAs mappen. Und das entspricht perfekt unserem Kachelkonzept der neuen Visu . Und das manuelle Erstellen von KNX Shuttern wird auch wegfallen, wenn es gut läuft.)
Sehr gut zusammengefasst. Mehrere Wege führen zum Ziel.
Damit stellen wir aber auch fest:
„richtig“ gibt es nicht. Und da andere Konfiguratoren, wie z.B. der MODBUS Konfigurator auch eine Variable „Value“ haben, wäre es aus meiner Sicht eigentlich sogar falsch, es bei KNX anders zu machen.
Wobei die neue ModBus Anbindung damit bricht (aus guten Gründen). Und der Semantic Export der ETS wird vermutlich auch bedeuten, dass wir in Symcon KNX Instanzen haben werden, die mehrere GAs/DPTs (=mehrere Variablen) gleichzeitig haben werden. Aber das ist Zukunftsmusik.
Daran hätte ich jetzt wenig Zweifel.
Alles was das Leben einfacher macht und auch Symcon noch besser für KNX geeignet macht, ist erstmal gut. Wenn man weiss wie gruselig die nativen KNX Visus mit den GAs umgehen (nämlich eigentlich gar nicht, alles händisch) dann wird das ein weiterer Push für Symcon und die KNX Visus können mal ihre 20 Jahre alten Systeme überarbeiten.
Was ich bisher in KNX gar nicht nutze sind die Funktionen da dies mE bisher null Mehrwert hatte. Wenn dies sich mit Symcon ändert, kann man sich das ansehen.
Und vlt kann man mit der ETS 6.1.1 ja mal 30 Min ohne Absturz arbeiten wie derzeit bei der 6.1 (daher nehme ich die nur wenn es gar nicht anders geht).
Daher wird das alles per Skript halbautomatisch erledigt.