RS IPS Project Exporter
Update 19.03.2014
Version 1.9, Bugfixes&Features -> siehe Changelog im Download
Intention:
Wer in IP-Symcon (ff. IPS) Projekte baut und die Scripte dem Forum zur allg. Nutzung zur Verfügung stellt, hat gemeinhin das „Problem“, die im Projekt befindlichen Objekte (Objektbaum-Elemente) zu managen. In der Regel baut man sich Installations-Logiken, die diese Objekte im Zielsystem installieren.
Komplexer wird es, wenn es um 1..2..3… viele Scripte geht. Man muss diese nicht nur -File für File- (oder als zip) zur Verfügung stellen, sondern auch deren Versionen lokal managen können. Mal eben den in einem der Scripte Code aktualisiert … und schon beginnt der Streß…
Das ist aber nur die Entwickler-Seite. Beim User geht es ja weiter: er muss die Scripte Installieren, verknüpfen, Variablen zuweisen, Variablenprofile erstellen und zuweisen, WFE-Objekte erstellen und mit den Quellobjekten aus dem IPS-Objektbaum verknüpfen….. Je nach Fähigkeiten des User kann hier reichlich schief gehen. Man sucht sich (im eigenen wie im Fremdsystem) zu Tode, nur um sicher zu stellen, dass die Installation exakt ausgeführt wurde….. Und dann kommen die evtl. vorhandenen, echten Bugs dazu. Bis dahin haben potenzielle User vielleicht schon die Lust verloren. Der Entwickler evtl. auch.
Hat man das aber überstanden, droht der nächste Horror: irgendwann wird ein Update notwendig. Die Ganze Arie nochmal: Der User muss alles exakt updaten und konfigurieren können. Wenn nicht, geht u.U. viel Zeit bei der Fehlersuche drauf. Und und und….
Hier setzt der IPS RS Project Exporter an:
Man installiert den RS Project Exporter (nur 1 Script!) in seinem System, setzt 1-2 Konfigurationsparameter (nämlich die ID des Projekt-Roots und das Projekt-Root im WFC). Das RS Project Exporter-Script ausführen – fertig. Es steht nun ein fix und fertiges (Export-) Script zur Verfügung, das ein vollständiges Projekt enthält. Dieses Script wird dann im Zielsystem ausgeführt – fertig. Man hat nun ein nahezu 1:1 geclontes Projekt (Ausnahme: Objekt-ID’s werden neu generiert) aus seinem Quellsystem im Zielsystem installiert, welches sofort lauffähig ist.
Bei Updates genau das gleiche Spiel: Quellprojekt auf genau die selbe Art und Weise exportieren, der User führt das Install-Script aus und – zack: hat er ca. 2000ms später eine exakte Kopie des Quellprojekts (in der neuesten Version) in seinem IP-Symcon.
Staun – wie geht das?
Der RS Project Exporter scannt rekursiv einen kompletten Projekt-Baum und sammelt die Konfigurationsdaten sämtlicher Objekte (incl. Script-Inhalte) ein. Genau das Gleiche macht er im Objektbaum des Webfronts – sofern eine WFC-ID angegeben wurde. Diese Daten werden komplett in einem Export-Script (mit Datumsangabe als Versionierungs-Hilfe) in einem lokalen Export-Ordner (im IPS-Objektbaum) abgelegt.
Dieses Script (das sogenannte ‚Install-Script‘) kann nun an Dritte weitergegeben werden. Der Empfänger muss dieses Script nur in sein IPS (Zielsystem) laden und einmal ausführen. Es werden nun alle Objekte des Quell-Projekts (incl. Webfront-Elemente) im Zielsystem installiert.
Wenn erforderlich, können die projekteigenen Installationsroutinen im Anschluss auf die neu erstellen Objektstrukturen zugreifen und diese konfigurieren. In einfachen Strukturen kann dies natürlich auch der Anwender machen.
Unter dem Strich
Ist der RS Project Exporter ein Werkzeug, welches die Projektentwicklung innerhalb der IP-Symcon Community pushen soll: sowohl versierte Programmierer werden von den eher lästigen Installationsroutinen entlastet (die sie ansonsten für jedes ihrer Projekte selbst entwickeln und testen müssten), also auch Einsteigern soll damit ein wenig die Angst vor komplizierten Programmierarbeiten genommen werden. Jede der beiden genannten Populationsgruppen wird entlastet und soll somit die Lust an der Veröffentlichung eigener Projekte innerhalb der Comunity pushen. Es steckt also schon ein strategischer Gedanke dahinter.
—————————————————————————————–
Kurzanleitung
Für Ungeduldige nur das Nötigste (die Anderen können unten weiterlesen ;-) )
- Project-Exporter-Script aus dem Download ins IPS importieren (z.B. in ein neu kreiertes Script)
- Project-Exporter einmal starten (legt Ordnerstrukturen und Child-Script „PE Export-Files“ an)
- ID des Quellprojektes in den Project-Exporter eintragen -> Project Exporter starten
- Install-Script des Quellprojektes wurde vom Exporter erstellt, dieses Script ins Zielsystem transferieren
- Script ausführen – fertig. das kopierte Projekt ist nun vollständig im Zielsystem und betriebsbereit
—————————————————————————————–
Feature-Übersicht
- Einfachste Handhabung des Projekt Exporters: in nur 3 Schritten zu einem Projekt-Clon (1x Script Projekt Exporter ausführen, 1 Exportscript an Zielsystem übergeben, Exporterscript im Zielsystem starten – fertig)
- Vollständiges, funktionsfähiges kopieren von beliebig komplexen Projekten aus IP-Symcon in andere IPS-Umgebungen (Ausnahmen: was geht nicht?)
- Beliebig viele, voneinander unabhängige Parallel-Installationen möglich, egal ob im Quell- oder Zielsystem
- Darüber hinaus kopieren von externen Files (Files, die nicht mit Objekten im IPS-Objektbaum verknüpft sind) und/oder kompletten Ordnern aus dem IP-Symcon Root-Ordner (mit Hilfe des Hilfs-Scripts ‚RS PE Export-Files‘). Diese Files können Scripte oder Grafik-Files sein
- Automatische Update-Funktion: wird beim Start des Installer-Scripts ein gültiges Logfile und ein gültiges Zielprojekt gefunden, schaltet das Script automatisch in den Updatemodus: fehlende Elemente im Zielprojekt werden angelegt, alle Objekte neu konfiguriert und verlinkt, Objekte unterhalb der Config-Kategorie werden nicht überschrieben
- Privacy-Mode true/false: bei true werden Variablen-Inhalte des Quell-Systems werden nicht exportiert (Datenschutz), bei false werden diese mit übertragen
- Automatische Neuverlinkung der innerhalb des Zielprojekts angelegten Objekte untereinander, auch innerhalb der Scripte!
- Events werden nach Installation im Zielsystem aus Sicherheitsgründen immer deaktiviert
- Automatische Versionierung der Exporte (via Datumsangabe)
- Script erzeugt ein nach Fehlerklassen sortiertes Installations-Protokoll (OK-Meldungen, User-Prüfung erforderlich und Fehler)
- Installer-Script legt nach Ausführung Protokollscript mit Installations-Protokoll und Installations-Inventory an (Voraussetzungen für spätere Updates)
- Online-Versionsprüfung und User-Info bei neuerer Version des Exporters (im Meldungsfenster des Scripts)
- Abwärtskompatibilität bis IPS V2.6: Projekte können zwischen IPS V2.6 bis IPS V 3.1 in beliebige Richtung kopiert werden. Versionsbedingte Änderung in IP-Symcon übersetzt der RS IPS Project Exporter automatisch (gilt für Objekteigenschaften, nicht für Scripte!)
Workflow (Export eines Projekts)
- Project Exporter öffnen und konfigurieren:
- $Root_ID: Root-Objekt des Projekts angeben (alle Objekte unterhalb des Root-Objekts [incl. des Root-Objekts] werden exportiert)
- Optional (nur, wenn WFE-Objekte mit exportiert werden sollen): Angabe des WFE-Konfigurators ($WFC_ID), der die zu exportierende Elemente enthält + Angabe des Quell-Item ($WFC_ProjectRootItem ), ab dem exportiert werden soll
- Sonderfall: Exportieren von Files (Dateien, die nicht mit dem IPS-Objektbaum verknüpft sind, z.B. js-Scripts, Grafik-Files):
- Nach dem ersten Start des Project Exporters legt dieser ein Child-Script (Name „RS PE Export-Files“) an
- Dieses Script muss in den Ordner „Config“ des zu exportierenden Projekts verschoben werden (Ordner „Config“ ggf. man. anlegen
- In diesem Script werden die zu kopierenden Verzeichnisse und/oder einzelenen Files definiert
- Script „RS PE Export-Files“ speichern, der Rest erfolgt automatisch
- Project Exporter ausführen
- Im IPS-Objekt Pfad „Z00 Projekte\RS Project Exporter: Export Dir\Project Export Ordner“ findet man nun das neu erstellte Export-Script
Workflow (Neu-Installation eines Projekts)
- Das Export-Script (ff. Installer-Script genannt) wird vom User ins Zielsystems in das Zielsystem importiert (Script anlegen, Export-Script-Inhalt reinkopieren)
- Ggf. konfigurieren (Angabe der WFC-ID, optionale Kopier-Parameter)
- Ausführung des Installer-Scripts im Zielsystem -> Quellprojekt wird im Zielsystem angelegt
- Kontrolle des Installationsprotokolls (befindet im Script-Meldefenster und im Installationsprotokoll), ggf. manuelle Nacharbeiten
- Fertig
Workflow (Update eines bestehenden Projekts)
- Voraussetzungen: ein bestehendes Zielprojekt im Zielsystem sowie ein gültiges Installationsprotokoll der letzten Installation/des letzten Updates
- User kopiert den Inhalt des Export-Scripts in das vorherige Installer-Script (von der letzten Installation/Update)
- Das Installer-Script wird ggf. konfiguriert (Angabe der WFC-ID, optionale Kopier-Parameter)
- Ausführung des Export-Scripts im Zielsystem -> das Zielprojekt wird auf den Stand des Quellprojekts (neue Objekte, Konfigurationsparameter) gebracht
- Kontrolle des Installationsprotokolls (befindet im Script-Meldefenster und im Installationsprotokoll), ggf. manuelle Nacharbeiten
- Fertig
was geht nicht:
Zunächst: der IPS RS Project Exporter übernimmt zwar sehr viele Installationsaufgaben und Konfigurations-Aktivitäten, er kann aber nur Aktor-Module (Enocean, Homematic etc) installieren – nicht aber deren Status-Variablen (welche vom Modul eigenständig erzeugt werden) nicht mit anderen Objekten verlinken und auch nicht konfigurieren. Das sollte beim Erstellen von Projekten entsprechend berücksichtigt werden.
- Media-Objekte werden nicht berücksichtigt
- Root-Ebene (ID 0) des Kategorie-Baums darf nicht kopiert werden
- Keine Verlinkung von oder mit Objekten außerhalb des Projektbaums
Nutzungsrechte:
- das Script darf für private, nicht kommerzielle Zwecke frei verwendet werden
- eine Weitergabe oder Änderung sowie auszugsweise Verwendung des Codes nur nach schriftl. Genehmigung des Autors
- für evtl. entstehende Schäden durch die Verwendung dieses Scripts wird keinerlei Haftung übernommen
Video Projekte exportieren: | Video Projekte importieren: |
Ziel-Publikum
Wem könnte eigentlich dieses komische Ding nutzen? Muss man das Tool haben? Muss ich mich etwa wieder in was komplexes, neues einarbeiten (IPS war ja schon heavy)? macht das abhängig?
Nun, ich würde nicht soweit gehen und sagen, dass es jeder braucht oder haben muss. Ich denke, der typische Anwender wird einerseits der IPS-Einsteiger sein (weil er ohne tiefergehende System-Kenntnisse schnell und easy ganze Projekte übernehmen kann), andererseits werden es vermutlich fortgeschrittene User sein, die entweder komplexere Projekte einfach verteilen oder ins Testsystem kopieren wollen, ohne dabei jedesmal aufwändige Installationslogiken schreiben zu müssen (na, ganz ohne wird es aus jetziger Sicht nicht gehen).
Einarbeiten muss man sich m.E. nicht. Es reicht, zu wissen, was eine ID und ein Objekt ist, wie ich ein Script ins eigene IPS kopiere, und wie ich im Script die ID zuweise. Und auf „Ausführen“ klicken sollte man auch können. Also eigentlich jeder IPS-Nutzer.
Infos für Projekt-Autoren
Sehr wichtig war mir bei der Entwicklung auch, möglichst wenig Abhängigkeiten zu erzeugen: das Tool ist ein Stand-alone-Script und das soll es auch bleiben. Man kann damit Projekte kopieren, die Projekte sind aber nicht von diesem Tool abhängig – da es keine Interaktionen gibt. Genau so wird es keine Interaktion oder Abhängigkeiten umgekehrt geben. Projekte können und sollten weiterhin so entwickelt werden, dass sie auch ohne dieses Tool auskommen (müssen sie aber nicht). Mit dem Project Exporter kann man allerdings den Installations-Code seht stark reduzieren und die Objektanlage und Konfiguration dem Projekt Exporter überlassen.
Tipps & Tricks für Projekt-Autoren
- Keine Verwendung von Sonderzeichen in IPS-Objektnamen (sowohl im Quell- als auch im Zielsystem) -> dies kann zu unerwünschen Effekten/Fehlern im Export-Script führen (besonders tödlich: ‚ [Hochkomma])
- Bei Option „$existsScriptsoverwrite = 1; “ vor Scriptausführung genau überlegen, was man tut! Hier werden nämlich bestehende und mit eigenen Namen versehene Scripts (Beispiel: „PHPSonos.inc.php„) auf File-Ebene gelöscht und neu angelegt. Gewöhnlich sind das Scripte, die Funktionen für das gesamte System zur Verfügung stellen – nicht nur für das aktuelle, zu importierende Projekt (falls dennoch ein Malheur passiert ist: das gelöschte Script ist nicht ganz weg sondern „nur“ aus dem Objektbaum entfernt und in den File-Ordner „/IP-Symcon/scripts/deleted“ verschoben
- Module für Aktoren (z.B. Homematic- oder Enocean-Instanzen) werden zwar kopiert, können aber vom Install-Script nicht verlinkt werden (da diese Module ihre eigenen Status-Variablen anlegen. Hier sollte innerhalb des Projektes eine eigene Zuordnungs-Logik eingebaut werden, falls auf diese variablen zugegriffen werden muss.
- Im Script-Meldefenster (Export-Script) werden alle Aktivitäten angezeigt, d.h. dort wird auch angezeigt, welche Objekte nicht vollständig konfiguriert werden konnten
- Werden Objekte im Quell-Projekt entfernt (weil nicht mehr benötigt), so sollten diese vom Anwender im Zielprojekt manuell gelöscht werden (der Projekt-Exporter löscht keine Objekte im Objektbaum), dies sollte man dem Anwender auch mitteilen
- Link-Objekte für WFE-Darstellung: empfohlen wird die Anlage eines separaten Link-Ordners (Kategorie) innerhalb des Projektordners. Hier können beliebige Linkstrukturen aufgebaut werden, die im Zielsystem ebenfalls automatisch korrekt angelegt und konfiguriert werden.
- Dem Anwender sollten die unmittelbar folgenden Tipps und Tricks für Anwender mitgegeben werden (so dass dieser z.B. die Updatefähigkeit seines Projektes sicherstellt), da dieser u.U. den Projekt-Exporter und dessen Arbeitsweise nicht kennt
Änderungen von Script-Inhalten im Configbereich des Quellprojekts: Ändert sich im Laufe von Release-Wechseln der Inhalt des Config-Scripts im Config-Ordner des Quell-Projekts, so hat der Projektautor zunächst ein Problem, denn die Objekte im Config-Bereich werden im Update-Modus im Zielsystem nicht überschrieben. Als Work-Around kann man wie folgt vorgehen:
- Das bisherige Config-Script vor dem Export löschen
- Anschließend das Projekt wie gewohnt exportieren
- Im Zielsystem wird nun dieses neue Config-Script parallel zum bestehenden Config-Script angelegt, das bestehende Configscript wird hingegen nicht verändert. Allerdings verlinkt Das Install-Script nun das gesamte projekt nicht mehr auf das alte, sondern auf das neue Config-Script
- Dem User muss nur noch klar gemacht werden, dass er seine individuellen Config-Angaben aus dem alten Config-Script in das neue übertragen muss.
- Anschließend kann (muss nicht) das alte Config-Script im Zielsystem gelöscht werden
Weitere Artikel zum Thema
Tipps und Tricks für Anwender
Will man sein installiertes Projekt updatefähig halten, muss zwingend das letzte Installationsprotokoll (welches nach der Installation unter dem Install-Script zu finden ist, Name endet auf „InstallProtokoll“) vorhanden sein. Ich löse das bei mir so, dass ich das Install-Script und das dazugehörige Protokoll in den Ordner „Config“ im installierten Projekt verschiebe (wenn der Ordner „Config“ nicht vorhanden ist, kann man diesen nachträglich anlegen, er wird vom Install-Script niemals überschrieben). So finde ich das zu Projekt gehörende Script und Install-Protokoll immer wieder. Update V1.2: ist ein Config-Ordner im Quell-Projekt enthalten, wird das Install-Script sowie dazugehörige Install-Protokolle automatisch ins Config-Verzeichnis verschoben
- Installierte Projekte (oder Teile davon) können innerhalb des IPS-Objektbaums beliebig verschoben werden: spätere Updates sind nicht gefährdet, da ein Update immer Objekt-ID basierend erfolgt, nicht struktur-basierend. Einzige Voraussetzung: ein zum bereits installierten Projekt passendes Installationsprotokoll
Schnelleres Arbeiten mit dem Install-Script (bei Updates): bekommt man vom Projektautor ein neues Installscript und will damit sein Zielprojekt updaten, reicht es völlig aus, nur den Part unterhalb des Konfigbereiches (Ab „Main Area“) aus dem neuen Install-Script in das im Zielsystem von der letzten Installation vorhandene Install-Script zu kopieren. Anschließend kurz den Konfig-Bereich des Scripts überprüfen und ab gehts: Update!
- Parallele Mehrfachinstallation eines Projektes: ein Projekt lässt sich beliebig oft parallel installieren, jedes der Projekte bleibt dabei individuell updatefähig (via Install-Protokoll). Dazu wird einfach das Install-Script n-mal im Zielsystem angelegt und ausgeführt. Die Zuordnung der Install-Scripte zu dem richtigen Zielprojekt lässt sich leicht über den Scriptnamen des Install-Scripts herausfinden: es enthält die Objekt-ID des Zielprojekts im Scriptnamen. WFE-Installationen, die zum Projekt gehören, werden ebenfalls parallel installiert und mit dem richtigen Projekt verlinkt (Details dazu hier)
- Neu-Installation eines Projekts: dazu einfach alle Install-Protokolle unterhalb des Install-Scripts löschen. Das Installscript geht dann bei erneuter Ausführung automatisch in den Install-Modus. Ein evtl. vorhandenes Projekt im Objektbaum muss vor der Neu-Installation nicht zwingend gelöscht werden.
Versionsinfos
Danksagung
Herzlichen Dank an Chef-Tester Werner (IPS-Forum: wgreipl) und IPS-Chefarchitekt Michael (IPS-Forum: paresy) für Unterstützung, Geduld, Tipps&Tricks und…und…
für kommerzielle Nutzung lizensierte Partner*
IPS-Forendiskussion
FAQ RS Project Exporter
wie erfahre ich, ob es ein Update gibt?
Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.
Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.
Wo finde ich einen Download?
Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)
*falls Interesse an einer kommerziellen Nutzung besteht, wende Dich gern an MICH