ich bin neu bei IP-Symcon und mir fällt es noch schwer das Prinzip des Objektbaumes zu verstehen.
Ich habe aktuell die KNX Gruppenadressen einer dimmbaren LED-Leuchte inkl TunnableWhite per .XML Datei importiert.
Jetzt habe ich aber im Objektbaum 7 Instanzen und darin dann die jeweilige Variable:
Instanz Ein/Aus
Instanz Dimmen
Instanz Wert
Instanz Ein/Aus Status
Instanz Wert Status
Instant Farbtemperatur
Instant Farbtemperatur Status
Wie gelingt es mir denn aus dieser LED-Leuchte EINE einzige Instanz/Geräte zu erstellen und darunter dann deren 7 Variablen übersichtlich anzuordnen?
Ich wollte mir gestern nämlich eine intelligente Kategorie-Kachel in die neue Tile Visualisierung einfügen, wo dann automatisch die noch eingeschalteten Lichter je Raum zur Übersicht angezeigt werden.
Habe im Forum dazu auch ein Beispiel gefunden aber in diesem Beispiel gab es nur eine Instanz für das Licht und darunter waren dann eben deren Variablen mit dem Profil ~Switch und ~Intensity.100
Mir gelingt es aber eben nicht, eine Instanz/Gerät zu bekommen und darunter dann deren Variablen.
Was mir da einfällt wäre dass Du die Status nur indirekt brauchst. Aber sinnvoll sind sie schon und zwar wenn Du zB bei der Schalt-Instanz bei „Mehr“ dort als „hörende“ den Status einträgst. Ditto bei Dimmen und Farbe.
Dann bekommst auch in der Visu mit dass in KNX etwas geändert wurde, ist ja wie mit jeder Visu. Der Unterschied zu „jeder Visu“ ist bei Symcon kannst das dann auch per Skript lösen, aber das sprengt grad den Rahmen.
Ich hab meine ich noch keine Kachel gemacht für TW, nur mit hue, aber ich würde zB die Schalt Instanz nehmen, da ist ja die Schalt-Variable drunter. Und dann linkst Du dort nur noch die Variable von Wert (Dimm abs) und Farbtemperatur rein. Dann hast unter der Instanz eben 3 Variablen, eine Originale und 2 Links.
Die Profile je Variable müssen stimmen, wie das für TW heisst weiss ich grad nicht.
Dann solltest eine passende Kachel bekommen.
Für eine Überschicht noch leuchtender Leuchten kannst Dir auch ein Dummy machen (oder auch eine String Variable) und darunter hängst Du die Links aller Leuchten die Du da sehen willst. Also die Schalt-Variablen.
Dann kannst noch leuchtendes auch schalten. Willst das dort nicht schalten können/dürfen, dann kannst auch die SchaltStatus nehmen und bei denen dann aber in der Variabeln je die „Standardaktion“ raus. Dann siehst den Status, kannst aber nix dran schalten.
Gibt es hier noch Lösungsvorschläge? Ich stehe bei der neuen Visualisierung nun vor dem gleichen Problem.
So bekommt man es bei einer dimmbaren Variable ja leider nicht angezeigt. Der AnAus Status muss aber in der gleichen Instanz sein. Das geht aber mit den KNX-Gruppenadressen nicht.
Das geht auf dem Umweg über eine Instanz vom Typ „Dummy“, unterhalb derer du Links auf die Variablen für KNX Schalten und KNX Dimmwert verlinkst.
Diese Dummy-Konstruktion sollte man ohnehin verwenden, um beim Aufbau des Visu-Baums flexibel zu sein. Du solltest die Visu also nicht direkt aus dem Baum mit den KNX-Instanzen erzeugen sondern besser einen separaten Baum nur für die Visu anlegen, wo du entsprechend mit Dummys und Links arbeitest. Das gibt volle Kontrolle über die Reihenfolge und Struktur für die Visu, unabhängig von Struktur der GA-Instanzen.
Ich habe ein Beispiel angehängt wie das bei mir aussieht.
Ich habe schon viele Visualisierungen machen dürfen und habe mir jetzt auch eine Symbox zum üben geholt.
Bei den anderen Visu‘s ziehe ich sozusagen einen Dimmer aus der Funktionsliste in die Visu rein und werde dann quasi „an die Hand“ genommen indem ich sehe, welche Kommunikationsobjekte zu verbinden sind also zB (Schalten, Schalten Status, Dimmen 4-Bit, Helligekitswert, Helligkeitswert Status und optional sofern vorhanden Farbtemperatur und Farbtemperatur Status).
So weiß ich direkt was zu tun ist. Bei der Symbox ist das nicht ersichtlich und so finde ich es ziemlich umständlich. Noch komplexer wird es dann noch, wenn man das „richtige Profil“ noch wählen muss.
IP-Symcon ist halt keine reine KNX-Visu und insoweit passt nicht alles 1:1 zwischen KNX und IPS. Die diversen GA einer dimmbaren Leuchte in ein Gerät zusammenzuführen ist bisher nicht automatisiert, deshalb hakt es hier.
Wie gesagt, der sinnvollste Weg ist eine selbstgebaute Baumstruktur und das Arbeiten mit Dummy-Instanzen und Links.
Was die unendlich vielen KNX-Profile (ein spezialisiertes Profil pro DPT) angeht so haben sich die IPS-Entwickler mMn selbst ein Beinchen gestellt, das wird bei der neuen Visu nun extra umständlich.
Mit der neuen ETS 6.1.1 und dem semantischen Export wird alles bald viel einfacher. Falls ihr zufällig auf dem KNX Professional treffen seid werde ich die erste Preview davon zeigen
Sorry Basti, aber das kann ich so nicht ganz stehen lassen.
Ich kenne ja nur Gira HS, Gira X1, Basalte und Symcon.
Du hast bisher vermtl. 1 oder 2 Symcon Visus erstellt.
Die reinen KNX Visu wie Gira und Basalte sind doch alle völlig zu Fuß wenn Du zB den Status anlegst. Jede einzelne geschi**ene Status Adresse muss ich da zu Fuß zuweisen.
Hast Du Dich da schon so dran gewöhnt dass Du es normal und gut findest?
Bei Symcon geht das beim Import völlig automatisch (wenn man sich an die einfache Konvention mit Status hält) oder ich mach es per Skript. Das Thema Status zuweisen ist also schon mal kein relevantes bei Symcon wenn man nicht einen völligen Verhau in seinen GAs hat. Aber dann hat man in jeder Visu Spaß.
Ist ja nett dass mir die Visus beim händisch anlegen helfen zu wissen dass ich noch dimmen, Status etc. brauche. Trotzdem muss ich jede einzelne GA per Hand zuweisen. In 2023?
Und sich jetzt für Dimmer oder Heizung in Symcon die paar Variablen zu verknüpfen ist bei 30 Stück (mehr hat es selten) nun wirklich kein Akt. Auch die Profile zuweisen ist extrem einfach. Die 30 markieren, bearbeiten und das Profil ist drin. Fertisch.
Und wie @paresy schon schreibt, wird Symcon mit dem neuen semantischen Export der ETS das nochmal erheblich vereinfachen.
Das hab ich genau noch nirgends gesehen, bin aber gespannt nächste Woche in Nürnberg bei den Professionals.
Klar, JEDE Visu hat eine Einstiegshürde, die gibts auch bei Symcon.
Aber bei Symcon wird sie laufend niedriger und der Gain wird laufend überproportional grösser. Das ist aber mit 1 oder 2 Projekten ggf. noch nicht erkennbar.
Zudem muss das nicht für jeden passen, für mich ist es definitiv ein erheblicher Wettbewerbsvorteil im KNX Umfeld. Und noch keiner der meine Symcon Visu gesehen hat, wollte danach noch seine vormals gesetzte HS, X1 oder Basalte haben.
Das Gira da als Marktführer und seit ewig bei KNX nichts halbwegs akzeptables hat, mag man mit Legacy erklären. Von Basalte bin ich da enttäuscht. Die konnten vor 4 Jahren bei null starten. Und es fehlen mir immer noch elementarste Dinge. Die hören auch nicht zu wenn man ihnen was sagt. Ja mei.
Ich bin happy mit KNX bei Symcon und Symbox und erzähl es jedem der es nicht schafft mich stumm zu schalten.
Ob es einer auch so sieht, ist dann nicht mein Problem.
Es gibt mehrere Wege. Einen Schritt sparen kannst wenn Du unter die SOLL Instanz den Link der IST-Temp als Link hängst. Dann die Instanz in die Tile-Visu Struktur verlinken. So sieht meine Instanz aus (hier am Beispiel Heizung mit Soll- Ist.
Die Temps bekommen das Profil ~Temperature.Room und schon geht das in meinem Fall mit Temperaturen oder bei Dir eben mit einer dimmbaren Leuchte.
Dass man auch einfach alle Temp Variablen markieren und das Profil allen auf einmal geben kannst, kennst ja vermutlich.
In der Tile sieht es dann so aus:
Von der Übersichtlichkeit finde ich den Dummy im Zweifel geschickter, wenn man die KNX Instanzen lässt wie sie sind, ist auch kein Fehler.
Aber am Ende eher Geschmacksache.
Naja, die Zuweisung von Status/Rückmeldungen ist automatisch wenn man die Namen in der ETS so anlegt wie der Import von IPS es gerne hätte. Da ist es natürlich von Vorteil, wenn man als Integrator beides in der Hand hat und beides von Beginn an aufeinander abstimmt.
Für den Privatnutzer der sein ETS-Projekt ohne Wissen um IPS-Besonderheiten angelegt hat wird die Automatik nicht unbedingt passen. Wenn man sich z.B. wie ich an den KNX Projektrichtlinien orientiert bei den GA Namen, dann funktioniert die Suffix-basierte Status-GA-Erkennung von IPS nicht.
da hast du mich wohl falsch verstanden bzw. ich habe mich nicht korrekt ausgedrückt!
Ich habe hier nicht davon gesprochen, wie man Gruppenadressen importiert…
Das nervt natürlich sehr beim HS4 wenn man zu jeder „Sendenden GA“ auch immer noch den Status als hörende Adresse anhängen muss.
Mir geht es erstmal um die Erstellung der Visu, wo ich als Symcon-Neuling sicher noch nicht so tief drin bin wie du. Ich habe aber auch nicht IP-Symcon schlecht gemacht sondern nur eine Art von „Verbesserungsvorschlag“ eingebracht.
Was ich sagen wollte ist, dass ich eben zb. bei anderen Systemen sehen kann, welche GAs zur vollen Nutzung dieser Funktion/Kachel benötigt werden. Ich hätte es eben toll gefunden, wenn man bei IP-Symcon zB. einen „Dimmer“ in der Instanz anlegt und darunter dann eben gleich die noch zu verknüpfenden Variablen angezeigt bekomme.
Am Beispiel eines anderen Herstellers will ich das Prinzip nur mal kurz darstellen:
Ich lege hier einen Dimmer inkl. TW Funktion an und sehe welche GAs es dazu braucht.
Da IP-Symcon nicht „nur“ KNX sprechen kann, ist es eben wohl so, dass auch die anderen Systeme hier berücksichtigt werden müssen und das Funktionsprinzip wohl anders ist als mir bekannt.
Vielleicht wird es ja mit dem Semantischen Export wieder ganz anders. Ich werde gespannt auf ein YouTube Video oder ähnliches warten!
vielen Dank für dein Feedback - für uns als Hersteller ist es ja immer Gold Wert, wenn Neulinge über Hürden sprechen und die auch gut erklären können (wie du mit Beispielen, wie es woanders ist), um die Denkweise zu verstehen. Vielen Dank noch einmal dafür.
Ich würde dir gerne ein wenig unsere Denkweise erklären und dir drei Dinge mitgeben:
a) Die kombinierten Kacheln (der neuen Visualisierung) sind super neu. Große Teile von IP-Symcon sind noch nicht darauf optimiert und insbesondere Systeme wie KNX mit einzelnen Gruppenadressen, die bisher „gut“ als Einzeladressen funktionierten, brauchen dort noch Anpassung. Deswegen auch dieser Umweg mit einem Dummy Modul + Link, sodass die Kacheln sich korrekt definieren. Die Übersicht aller Kacheln und was diese benötigen findest du übrigens hier: Objekt-Darstellung — IP-Symcon :: Automatisierungssoftware Es bleibt immer noch die umgedrehte Denkweise, aber vielleicht hilft es schonmal zu verstehen, woher die Jungs ihre Infos haben und wo wir alles in der Doku so verstecken
b) Mit dem semantischen Export (und den Funktionsbausteinen der ETS) verlagert sich die ganze Sache in die ETS. Dort wirst du genau diese Funktionsblöcke (Licht, Rolladen, HVAC) definieren, wie diese in dem anderen Programm jetzt erst für die Visu manuell gemacht werden. D.h. wenn du Funktionsblöcke in der ETS nutzt, wird der semantische Export diese Infos bald nach Symcon liefern und wir werden die Instanzen inkl. der kombinierten GAs automatisch erstellen. Die Kacheln werden also automatisch richtig aussehen - das liegt aber nicht daran, dass wir dich in Symcon bei der Erstellung geführt haben, sondern am Semantischen Modell, welches das ETS Projekt direkt mitgeliefert hat. Da werden die Namen und Struktur der GAs auch kaum mehr relevant sein und die alten Hasen werden sich dafür umgewöhnen müssen. Dafür wird die Einrichtung der Visu, sofern man sich an die neue Semantik gewöhnt hat, ein Kinderspiel bei der Einrichtung. Für ist das aber wahrscheinlich zu spät - du magst ja jetzt fertig machen und es schick haben. Deswegen die Tipps aus a). Falls nicht und du dein ETS Projekt mit der 6.1.1 noch etwas umstricken magst → Ich werde bestimmt im Laufe des Dezember noch ein Video dazu erstellen.
c) Zu unserem Event (Ende Januar 2024) werden wir auch Verbesserungen am Profil-Manager vorstellen, die diese Problematik zwar nicht vollständig lösen, aber definitiv wird es der erste Schritt in diese Richtung sein. Mehr direkt auswählen und sehen was man möchte mit mehr Hilfestellung wie man dort hinkommt
Es ist für uns mit der neuen Visualisierung auf jeden Fall eine extrem spannende Zeit, weil wir damit viele Möglichkeiten haben, die es bisher nicht gab → Die Umstellung und Anpassung muss jetzt nur noch an vielen Ecken geschehen. Und da sind wir dran!
Weder noch Basti
Ich hab nur den Bezug vergrößert da es ja nicht nur den einen Aspekt gibt der Symcon unterscheidet. Der Punkt der Dir heute nicht gut gefällt ist schon klar, aber m.E. halt bisher noch ein kleines Manko wenn ich die vielen anderen Dinge in die Waagschale werfe die für mich Symcon speziell für KNX vorteilhaft machen.
Und good news für alle ist ja dass es mit dem semantischen Export/Import Dein Thema löst und auch gleich die Dinge die heute sonst bei anderen Visus nerven (Status).
Bin echt gespannt auf diese Woche was MIchael da vorstellt.
@volkerm
Ich orientiere mich bei meiner Benennung der Gruppenadresse größtenteils an den Empfehlungen der KNX Association, welche Du als Screenshot hier gepostet hast. Bei mir funktioniert das automatische Zuweisen der hörenden Adressen perfekt. Genau diese Empfehlungen sind auch ein wenig die Basis für das Feature der automatischen Erkennung gewesen.
Wenn du magst, schick mir gerne einen XML Export von dir und ich schaue mir das mal an.
nach meinem Verständnis funktioniert die Erkennung der Status-GA in IPS immer dann, wenn der Name der Basisfunktion mit einem zusätzlichen Suffix kombiniert wird. Also beispielsweise „Wandleuchte“ und dazu „Wandleuchte RM“.
Was nach meinem Verständnis nicht funktioniert ist das Zusammenführen von zwei unterschiedlichen Suffixen, wie sie in den KNX Projektrichtlinien verwendet werden, also für das Schalten „Wandleuchte E/A“ und zugehörige Rückmeldung „Wandleuchte RM“.
Ich schicke dir mal meinen Projektexport, vielleicht übersehe ich ja was!
Ich habe mir Volkers XML Export angesehen. Wenn man die Empfehlungen der KNX Association zu 100% umsetzt, erkennt IP-Symcon die hörenden Adressen nicht automatisch.
(Ich persönlich verwende „Status“ anstatt „RM“ - das ist aber Geschmackssache.)
Die Gruppenadresse 1/1/5 wird in diesem Beispiel automatisch korrekt der 1/1/3 als hörende Adresse zugeordnet. Die 1/1/4 wäre die hörende Adresse zur 1/1/1 - was IP-Symcon aber logischerweise nicht erkennt.
Natürlich entspricht IP-Symcon hier nicht 100%ig den Empfehlungen der KNX Association, aber bzgl. E/A und RM finde ich diese hier auch nicht konsequent zu Ende gedacht - ich würde sogar sagen fehlerhaft. Schaut man sich die Empfehlungen für Jalousien an, so heißt es dort es „Wert“ und „RM Wert“. Daher wäre bei Schaltkanälen „E/A“ und „RM E/A“ logisch gewesen. Gerade auch für den Einsteiger, der mit KNX noch nicht viel zu tun gehabt hat, wäre dies einfacher zu verstehen.
Daher finde ich die Lösung der Symcon GmbH hier konsequent und absolut perfekt gelöst.
Absolut perfekt halte ich für Werbesprech. Wie ich oben schrieb: momentan muss der Kunde bereits bei den GA-Namen an diesen IPS-Import denken, dann funktioniert es. Die Erkennung der Zusammenhänge aus den GA-Namen ist schwierig, aber das ist auch ein selbstgemachtes Problem weil IPS bisher nur die GA-Liste liest und alle anderen Informationen aus dem ETS-Projekt nicht nutzt.
Ich bin froh dass paresy sich nicht damit zufrieden gibt und mit dem kommenden semantischen ETS-Export eine umfassendere Lösung erarbeitet hat. Das wird spannend und weil es viel Potential hat für jegliche Visu werden solche Strukturdaten hoffentlich bald zum Standard beim Erzeugen von ETS-Projekten gehören, anstatt reiner GA-Schubserei.
)
