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.
Im Vergleich z.B. zum GIRA X1, wo ich wirklich jede Gruppenadresse ausnahmslos händisch anfassen muss, ist es bei IP-Symcon absolut perfekt.
Da bin ich auch froh. DIe ETS 6.1.1 bietet die Möglichkeit und ich vermute, dass andere Hersteller in ca 3-4 Jahren auch nachziehen werden. Ich bin wirklich froh, dass die Symcom GmbH hier sehr nah am Zeitgeschehen ist und IP-Symcon ständig weiterentwickelt wird.
Ja, und hoffentlich ziehen dann auch die Integratoren mit, anstatt ihre gewohnten Pfade weiter zu nutzen.
Ich vermute dass nun die zu Zeiten der ETS Inside eingeführten „Funktionen“ innerhalb der Gebäusestruktur wichtig werden, die seit Jahren auch in der ETS Pro verfügbar sind. Damals hatte ich im KNX-UF den Eindruck dass die Integratoren sehr an ihren GA-Strukturen und der vollen Kontrolle über die Nummernkreise hängen und sich dagegen sträuben, mit Funktionen zu arbeiten und die GA von der ETS im Hintergrund erzeugen zu lassen.
Da war die Technik gefühlt schon weiter als viele Integratoren, die ihre alte Pfade nicht verlassen wollten. Hoffentlich gibt es hier ein Umdenken, sonst hängen wir ewig an den GA…
Bisher gab es auch - ehrlich gesagt - keine Anreize es zu tun. Das ändert sich langsam. Die 6.1.1 ist da auch nur eine Zwischenlösung, da keine neuen Funktionen dazugekommen sind, sondern es nur die paar wenigen gibt. Und die 6.2, die wohl zur L+B 2024 kommen soll, wird da erst richtig mehr mitbringen und dies auch mit mehr neuen Funktionen für die Produktivität garnieren. Immerhin passiert etwas → und meiner Meinung nach auch in die richtig Richtung.
Wenn es das Leben leichter macht und uns vorwärts bringt, hat doch jeder Lust auf was Neues.
Hab bisher nur keinerlei Nutzen mit den Funktionen gesehen was mir in Richtung Symcon oder in der ETS geholfen hätte.
Die ETS Inside hatte ja das Grundprinzip gezeigt: anstatt diverse GA zu verbinden wird eine „Funktion“ des Sensors mit einem „Kanal“ des Aktors verbunden. Schon praktisch, oder?
Die Zuordnung von Funktionen in der Gebäusestruktur hätte man auch gleich in der *.knxproj verfügbar gehabt, sofern man diese eingelesen hätte.
Dieses neue Konzept fand man auch in der ETS Pro wieder, aber es wurde wenig beachtet bzw. belächelt, und die Applikationen einzelner Hersteller (z.B. MDT) haben das offenbar nicht voll unterstützt.
Ob es für die Praxis damals schon nutzbar war kann ich nicht beurteilen, für mein Projekt kam das zu spät.
Ja, die Idee mochte ich auch. Hab leider in der Praxis bisher keine Nutzung finden können, dachte Du wärst da vlt. schon weiter gewesen.
Du darfst Dir sicher sein, dass genug, sicher Christoph und ich, hier an vorderster Front dabei sein werden, um die Möglichkeiten der Funktionen via semantischem Export/Import zu eruieren.
Wenn es Zeit, Mühe oder Beides spart, würde das sicher jeden begeistern der produktiver und schneller seinen Kunden helfen will.
Sepp, das würde mich freuen! Meine Bedenken waren/sind dass die Integratoren sich bisher mit selbsterfundenen Strukturen/Namenskonventionen und entsprechenden Scripten in IPS beholfen habe, das halbautomatisch zu erzeugen, was eben sehr individuell ist aber durchaus schnell sein kann. Ob das Anlegen der Strukturen in der ETS dann effizienter/schneller ist wird sich zeigen.
Der Vorteil der ETS-Lösung wäre in jedem Fall eine standardisierte Vorgehensweise, die nicht auf eine spezielle Visu und den persönlichen Workflow des Integrators beschränkt ist.
Das ganze soll wiederkommen und besser gemacht werden. Theoretisch haben wir dies ja seit der ETS 5 mit dabei (https://www.youtube.com/watch?v=mkbgH79m1qo&ab_channel=KNXAssociation) aber bisher haben die Hersteller sich nicht gekümmert die Produktdatenbanken zu verbessern. Damit das perfekt funktioniert, müssen die auch mitarbeiten. Das ist aber die KNXA jetzt dran, damit da endlich etwas passiert. Und hoffentlich sehen wir erste Früchte zur L+B '24.
Kurze Korrektur → Die Wörter sind nicht Suffixe. Die können egal wo stehen. D.h. die RM WERT Variante mit " rm" würde ebenfalls funktionieren. Ich finde die Idee einer weiteren Liste die das E/A entfernt auch nicht verkehrt - das würde (hoffentlich) alle Wünsche lösen. Wenn du mir deine XML mal zusendest, dann teste ich das aus.
