Tipps&Tricks zu IP-Symcon: Arbeiten mit Links
aus meiner Reihe „IP-Symcon Erfahrungen, Tipps und Tricks„. heute:
Visualisierung – möglichst nur mit Links arbeiten!
Fängt man mit IP-Symcon an zu arbeiten, fällt es schwer, die Übersicht zu behalten – weil das Tool so mächtig ist. Also fängt man erstmal an, sich einen Objektbaum aufzubauen, die Objekte für Aktoren, Sensoren & Co. anzulegen und zu konfigurieren. Natürlich möchte man dann auch was sehen. Man sieht also zu, wie man möglichst schnell die gerade mühsam angelegten Objekte in die Visualisierung bekommt. Das Werkzeug dazu heißt Webfront-Konfigurator (im Folgenden WFC). Wie macht man es? Nun – den nativen Eingebungen folgend: man legt im WFC auch Kategorien (oder was sich sonst noch an Optionen bietet) an und verlinkt diese mit den gerade angelegten Objekten im Objektbaum. Perfekt! Geniale Lösung – funktioniert sogar!
Wirklich?
Nun, auf den ersten Blick: ja. Auf den Zweiten Blick: nicht so gut.
Warum?
Es gibt hier mehrere Gründe, warum dieses Vorgehen eher früher als später zu spürbaren Nachteilen führt.
- Früher oder später wird man auf die Idee kommen, das visualisierte Objekt an einer anderen Stelle im Webfrontend oder in einem ganz anderen Webfrontend – und dann vielleicht noch in einem anderen Kontext darstellen zu wollen. Dann wird auch ganz schnell der Wunsch aufkommen, dem darzustellenden Objekt einen anderen Namen zu geben. Mit einer Direkt-Darstellung (also direkt aus dem WFC auf das Objekt verwiesen) ist dies aber nicht möglich.
- Benennt man Status-Variablen (z.B. von Homematic-Aktoren) um, läuft man nach einiger Zeit Gefahr, deren ursprüngliche Bezeichnung zu vergessen. Das ist soweit nicht dramatisch – schließlich kennt man sich im eigenen IPS-System bestens aus! Ja- aber Dritte nicht! Spätestens dann, wenn man im Forum Hilfe braucht oder ein Supporter ins eigene IPS schaut… na ja, den Rest kann man sich denken
- Anforderungen an Visualisierung und „operative“ Strukturen lassen sich auf Dauer nicht in Einklang bringen: man wird nicht umhin kommen, seine Aktoren, sensoren und Scripte im Objektbaum nach einem bestimmten Schema anzuordnen, zu strukturieren. Während man sich im Objektbaum der Konsole vermutlich nach geographischen oder funktionalen Gesichtspunkten organisiert, hat man es im Webfront eher mit einem kontextbezogenen Design zu tun. Alle eben genannten Anforderungen gleichermaßen zu erfüllen ist schlichtweg unmöglich


Die Vorteile (durch Arbeiten mit Links) kurz zusamengefasst:
Visualisierung und „operative“ Strukturen im Objektbaum können getrennt und völlig unabhängig strukturiert werden (Trennung von Design und Funktion)
- individuelles, kontextbezogenes Design der zu visualisierenden Objekte (Bezeichnung, Stuktur der Darstellung)
- beliebige, unabhängige Parallel-Visualisierungen für ein und die selben Funktions-Objekte