Hi @ll,
habe eben die V0.6 (jetzt BETA) online gestellt (Download wie immer via Projektthread)
Auszug aus dem Changelog:
2012-10-07 V0.6
Bugfixes
- WFC-Root-Itemname ist nun beliebig (bisher fest „roottp“) und wird automatisch gefunden
Bin mal echt gespannt, wie oft das auf einen Fehler läuft (siehe Posting #40) 
hi bb, @ll,
noch ein paar Gedanken zur Verlinkung von Objekten ausserhalb des Copy-Projekts:
ich hab das nochmal gründlich durch die Grübel-Instanz geschossen. Im Ergebnis ist das alles machbar, aber die Fehlerwahrscheinlichkeit steigt erheblich. Und das will ich eigentlich vermeiden.
Details:
Szenario: Quellprojekt beinhaltet verlinkte Targets ausserhalb des Projektes (z.B. Trigger-Variablen). Das Quell-Projekt wird in ein neues Zielsystem kopiert. Nehmen wir an, die Target-Variablen exisitieren dort schon.
Verlinkungslogik wäre eine 3-stufige:
Stage1: Verlinkung innerhalb des Copy-Projekts auf Basis der oldID <-> newID (heute implementiert)
Stage2: Verlinkung ausserhalb des Copy-Projekts via Target-ID + TargetName (würde nur funktionieren, wenn Quellsystem = Zielsystem ist, heute nicht implementiert)
Stage3: Verlinkung ausserhalb des Copy-Projekts via TargetName (das Zielobjekt wird im Objektbaum des Zielsystems über den Objektnamen identifiziert, heute nicht implementiert)
Um beim obigen Szenario zu bleiben, käme in diesem Fall nur Stage3 in Frage: ich würde den namen des alten Zielobjektes im Objektbaum des Zielsystems suchen und bei Treffer darauf verlinken.
Problem A: Objektname wird nicht gefunden, weil Objekt inzwischen umbenannt (Haken dran, irgendwas ist ja immer)
Problem B: Objektname (Beispiel: HM-Instanzvariable „State“) wurde gefunden, das Objekt im Copy-Projekt wird mit dieser, ausserhalb des Copy-Projkets liegenden Trigger-Variable verlinkt. So weit- so gut. Irgendwann stellt der Anwender fest, dass sein Projekt nicht so richtig funktioniert. Nach Fehlersuche stellt sich raus, dass die Verlinkung zwar richtig auf „STATE“-Variable erfolgt ist, leider gab es im Zielsystem aber schon 12 Variablen mit dem Namen „State“, und statt der 9. Variable ist die 1. verlinkt worden.
Problem B führt also zu Problemen, deren Fehler und Folgeschäden der Grund dafür sind, dass ich es bisher nicht eingebaut habe.
Wenn hier jemand andere Ideen hat, die zu einer effizienten Problemlösung führen, immerher damit, bau ich gern ein 
Ich denke, die empfohlene Vorgehensweise für einen Projekt-Export wäre heute die:
Alle Links, die für eine WFE-Darstellung benötigt werden, innerhalb des Projektbaums platzieren. Dann funktioniert ein Export incl. WFE-Part problemlos
Lösungsvorschlag hab ich erstmal keinen, außer wie du schon sagst das Links nur in den zu exportierenden Pfad zeigen dürfen.
Ist ja irgendwie auch logisch. Das was ich machte kann ja eigentlich gar nicht gehen. Zumindest nihct wenn man auf ein fremdes System exportiert. Und dazu ist der Exporter ja da.
Wollte nur mal ganz dumm probieren und da bin ich halt darübergestolpert.
Laß es besser robust und einfach als mit zu vielen Konfigurationsoptionen.
gruß und schönes Wochenende
bb
hier ein paar Anmerkungen zum Projekt http://www.ip-symcon.de/forum/threads/19677-Z-Wave-Netz-Visualisierung-Überwachung:
Hi McFly,
schön, dass sich mal einer an den Project Exporter rantraut Ich hab zwar kein Z-Wave, wollte aber natürlich mal wissen, ob der Project Exporter auch in freier Wildbahn seinen Dienst tut.
so reibungslos scheint es nicht geklappt zu haben, ein paar Anmerkungen:
[ul]
[li]3,5 tausend Zeilen aus dem Wbebrowser auskopieren ist ganz schön anstrengend -> wesentlich charmanter wäre ein Download (.zip o.Ä.)[/li][li]irgendwas ist beim Export-Script schief gelaufen: die Auskommentierungen im Script-Kopf sind kaputt, das Script lässt sich so nicht ausführen (ich habs bei mir repariert, dann geht es). Was mich hier interessiert: hat der Export-Mechanismus noch ne Macke? Hast du ne Idee, wie der Fehler zusstande gekommen ist?[/li][li]man sollte das Export-Script lokal einmal testen und schauen, ob auch alles richtig angelegt wurde. Das kann man ohne weiteres auch im Quellsystem machen. Ein paar Links liegen scheinbar ausserhalb des Copy-Projektes, so dass im Zielsystem nicht alles ankommt.[/li][/ul]
Alles nicht dramatisch, vielleicht muss ich im Workflow noch was anpassen, um die Bedienung sicherer zu gestalten.
Wäre super, wenn wir uns hierzu kurz austauschen können, vielleicht auch im Projekt-Thread, um hier nicht allzusehr in den OT zu rutschen
Danke fürs Testen.
Lokal hat das Installationsscript funktioniert.
Das Problem ist der Zeilenumbruch im Forum. Die Kommentarzeilen waren zu lang uns schon war das /* */ Geschichte.
Copy Paste zusammen mit den bekannten Mauskombinationen (Shift-links) fand ich jetzt nicht soo schlimm.
Aber ich packe das Script mit in das Archiv. Dann sind alle Umbrüche wie sie sollen.
Zu den Details:
Der eine Link kann nicht komplett übernommen werden, da er auf „externe“ Z-Wave Geräte zeigt. Ist hier aber nicht schlimm, da er eh von meinem Script dynamisch erstellt wird. Könnte ich auch einfach rauslöschen vor dem exportieren.
Das Variablenereigniss allerdings sollte eigentlich klappen. Sie verweist auf eine Variable in dem zu exportierenden Ast.
Das Ereignis ist auch richtig angelegt. Nur der Name ist falsch und es ist nicht aktiv. Wenn man es über den Dialog aktiviert funktioniert es wie gewünscht.
Das Zeitereignis ist jedoch korrekt deaktiviert.
Anbei der Ast nach dem Import.
cu…
prima, das sieht ziemlich gut aus (aus Exporter-Sicht), danke dir für Deine Mühe
Zum Ereignis:
Das Variablenereigniss allerdings sollte eigentlich klappen. Sie verweist auf eine Variable in dem zu exportierenden Ast.
Das Ereignis ist auch richtig angelegt. Nur der Name ist falsch und es ist nicht aktiv. Wenn man es über den Dialog aktiviert funktioniert es wie gewünscht.
Das Ereignis wird mein Anlegen im Zielsystem standardmässig deaktiviert (aus Sicheheitsgründen). Die Überlegung, die dahinter steckt: Falls das Projekt noch eigene, nachlaufende Installationslogiken mitbringt, oder der User geplant und manuell Nachkonfigurieren soll, ist es besser, dafür zu sorgen, dass im Copy-Projekt nicht unkontrolliert Aktivitäten starten.
Daher ahbe ich alle Events auf „disabled“ gesetzt. Zu überlegen wäre hier, ob nichtzyklische Events bei Installation aktiviert werden dürfen (dann bleiben nur die zyklischen Events diabled). Ich lass mir das mal durch den Kopf gehen. Eure Meinung interessiert mich dazu auf jeden Fall.
Zur Benamsung des Events: das ist ein unbenanntes Event gewesen, schon im Quellprojekt. Nur dass IPS dort einen Text reinsetzt (ch vermute dynamisch zur Laufzeit - wie auch bei den ID-Pfad-Kommentaren im Script), der es wie eine Benamsung aussehen lässt. Benennst du das Event vor dem Export explizit manuell, wird der Name auch korrekt übernommen.
Prima, prima, sieht doch ganz gut aus.
Nochmals vielen Dank für den „heißen Beta-Test“
Das mit dem Namen des Ereignisses ist ja gemein.
Bei dem Original wird einfach nix angezeigt und im Export kommt das „unbekannte Objekt“.
Im Original wird dieses übrigens auch als neuer Name vorgeschlagen. 
Zu den Variablenereignissen. Da bin ich auf jeden Fall der Meinung, dass Eventereignisse immer mit dem Zustand übernommen werden sollten der das Original hat (aktiv oder inaktiv).
Dürfte bei vielen Projekten eine Kernfunktion sein, das bei Wertänderung etwas passiert.
Wenn der Benutzer dann alle von Hand aktivieren muss schwindet der Mehrwert des Exporterscriptes.
Ereignisse, die auf externe Objecte verweisen (wer macht den sowas :rolleyes: ) sollten aber deaktiviert bleiben.
cu…
Schau mal den Export meines WF bei wupperi:
Wo kommt die Leiste oben rechts her?
Die ist bei mir nicht drin. Im Konfigurator sehen beide Versionen erstmal gleich aus.
cu…
Kannst du mal einen Screenshot vom WFC zu dem teil oben einstellen?
hat sich erledigt, ich hab das „Problem“ eingrenzen können:
der „tote“ Link „Wasserbett“ kann vom Exporter nicht verlinkt werden, weil das target ausserhalb des projektes liegt. Daher setzt IPS bei der Anlage des Objekts den Link „0“ als Defaultwert und es erscheint im WFE eine kategorie „Wasserbett“. Ich hab probehalber diesen Link auf eine reale Instanz verlinkt, schon erscheint ein Ergebnis, was dem des Ursprungsprojekts näher kommt:
Merke: keine Leichen aus dem Quellprojekt exportieren
ich schau mir das mal an, ob ich den Fehler irgendwie abfangen kann (vermutlich nicht),
Supi, danke.
Man muss „nur“ dran denken solche Links vor dem Export zu löschen.
Allerdings sollte der Fehler auch beim ersten richtigen Verlinken wieder behoben sein.
cu…
Hi @ll,
habe eben die V0.7 (jetzt BETA) online gestellt (Download wie immer via Projektthread)
Auszug aus dem Changelog:
2012-10-13 V0.7 Features
* formatiertes Install-Protokoll eingebaut
* ausgelöste Events werden nun standardmässig nach der Installation aktiviert
(zyklische Events bleiben weiterhin inaktiv)
hier ein paar Bilder zum formatierten Protokoll
es werden Meldungen nach Meldungsklassen ausgegeben
[ul]
[li]OK-Meldungen (nur zur Info und um eindruck zu schinden )[/li][li]Kontrolle durch User erforderlich (in der Regel Verlinkungen, die nicht hergestellt werden konnten, weil Target-Objekt ausserhalb des Copy-Projektes liegt, sollte durch manuelles nacharbeiten durch den Anwender oder durch vom Projektautor mitgelieferte Installationsroutinen ergänzt werden)[/li][li]Fehlermeldungen (harte Fehler im Script oder Zielsystem, in der Regel konnte das Objekt nicht angelegt werden)[/li][/ul]
hm, ich glaube ich stehe auf dem Schlauch.
Ist die php Datei aus dem Projektthread richtig?:
/**********************************************************************************************************************
* this Install-Script was automated generated by IPS RS Project-Exporter *
* © by Raketenschnecke 2012, mail: raketenschnecke@gmx.de *
* // Projekt-HomePage: http://www.raketenschnecke.net/2012/09/25/ips-rs-project-exporter/ *
**********************************************************************************************************************/
/**********************************************************************************************************************
Project: Logging.DB Monitoring (Quell-ID: 20257), generated on 30.09.2012, 20:11 Uhr
*
sieht irgendwie wie ein Export eines anderen Projektes aus.
cu…
wenn Du die Datei im Bild meinst: ja, das ist ein BEISPIEL-Projekt
hm, dann wärs vielleicht besser direkt auf die Seite zu verlinken.
Ist irgendwie ein Reflex: Anhang->will haben. :o
cu…
Hi @ll,
habe eben die V0.8 online gestellt (Download wie immer via Projektthread).
Die Änderungen sind für Aussenstehende eher marginal bzw. kosmetisch.
Auszug aus dem Changelog:
2012-10-17 V0.8
Feature
* diverse Code-OptimierungenBugfixes * Fehlerhafte Protokoll-Message #6010 korrigiert * Korrektur Zeilennummer-Anzeige bei Scriptänderungen(Anzeige der Zeilennummer in Scripts war um 1 versetzt) * Neuverlinkung zyklischer Events entfernt (weil unnötig, produziert irritierende Protokollmeldung)
Vorbereitung zur Implementierung eines Update-Modus
möglicherweise wird es demnächst eine Update-Funktion im Project Exporter geben. Im Moment bin ich da noch in der Konzeptphase.
Es schält sich aber heraus, dass es eine Implikation für Projektautoren geben wird: der Umgang mit anwenderbezogenen Konfigurationen (wie Mailadressen, ausserhalb des Projekts liegenden Variablen etc). Um diese nicht nach jedem Update neu konfigurieren zu müssen, steht die Überlegung im Raum, eine spezielle Kategorie Namens “Config” vorzusehen, wo bei Updates die darin befindlichen Objekte nicht überschrieben/neu konfiguriert werden. Es hat evtl. Vorteile, dies in den aktuellen Projekten jetzt schon zu berücksichtigen (z.B. durch Auslagern der Konfig-relevanten Scriptteile in ein Script innerhalb der Config-Kategorie und anschließendes includen dieses neuen Config-Scripts in den ursprünglichen Scripts). Weiterhin wird die Update-Option ein Vorhandensein des letzten Installationsprotokolls voraussetzen. Das sollte man seinen “Kunden” evtl. schon jetzt mit auf den Weg geben
Für Interessierte (gerne auch zur Diskussion) das aktuelle Update-Konzept
Funktionsweise (Konzept)
[ul]
[li]Das Export-Script schaltet immer dann automatisch in den Update-Modus, wenn mindestens ein Installationsprotokoll als Child vom Export-Script gefunden wird[/li][li]Als Update-Basis wird immer das jüngste Installationsprotokoll unter dem Export-Script eingelesen[/li][li]Für individuelle Konfigurations-Daten kann eine „Config“-Kategorie angelegt werden: alle darin befindlichen Objekte werden beim Update nicht bearbeitet. Lediglich neue Elemente werden hinzugefügt[/li][li]Im Update-Modus wird nur die Konfiguration bestehender Objekte (z.B. Parametrisierung in einem Hauptskript) mit der Konfiguration aus dem Quellprojekt überschrieben (Ausnahme: „Config“-Kategorie und alle darin befindlichen Objekte)[/li][li]Scripte werden auf File-Ebene ausgetauscht (Script-ID bleibt gleich)[/li][li]Im Quellprojekt neu hinzugekommene Objekte werden im Updatemodus auch im Zielprojekt angelegt und konfiguriert[/li][li]Variablenprofile werden erneut angelegt[/li][li]WFC-Teilbaum alt wird gelöscht und neu installiert (dann immer auf Ebene 0),[/li][/ul]
Hi @ll,
habe eben die V0.9 online gestellt (Download wie immer via Projektthread).
Die Änderungen sind für Aussenstehende eher marginal bzw. kosmetisch.
Auszug aus dem Changelog:
2012-10-21 V0.9Feature
* Update-Funktionalität eingebaut: bei vorhandenem Zielprojekt UND Protokollfile automatisch Update-Modus
* Config-Ordner: Objekte im Config-Ordner werden im Update-Modus nicht bearbeitet (Ausnahme: im Zielprojekt
fehlende Objekte werden angelegt und konfiguriert)
* alle vorhandenen Logfiles werden automatisch gelöscht (Ausnahme: jüngstes Protokoll)
Vom Handling ist das Tool meiner Meinung nach sehr einfach (auch wenn der riesige Text vielleicht einen anderen Eindruck vermittelt, hier fehlt mir noch ein wenig Feedback ;)), aber die Entscheidungslogiken im Script sind schon etwas tricky. Es ist sicher hilfreich, diese zu kennen, daher ein paar Details zur Update-Logik:
Ziel
Die Updatefunktion innerhalb des Project-Exporters ist dazu gedacht, Änderungen/Erweiterungen im Quellprojekt möglichst einfach an Dritte auszurollen. Einen zusätzlicher, updatespezifischer Aufwand (besondere Konfiguration etc) ergibt sich für den Projektautor nicht.
Das vom Project Exporter erzeugte Export-Script beinhaltet eine automatische Update-Erkennung: findet es im Zielsystem Install-Protokolle als Childs von sich selbst, schaltet es selbständig in den Updatemodus. Um ein Update im Zielsystem auszuführen kann der Anwender direkt auf eine bestehende Projektinstallation aufsetzen und muss keinerlei zusätzliche Konfigurationen vornehmen.
Update-Ablauf (für bereits im Zielsystem vorhandene Projektinstallationen):
Idealerweise wird das Exportscript in das im Zielsystem bestehende Export-Script kopiert. Beim Aufruf checkt das Update-Script nun vorhandene Child-Logfiles und wählt das jüngste Install-Protokoll aus den Childs als Update-Basis aus. Findet das Export-Script kein geeignetes Install-Protokoll, bleibt das Exportscript im Installations-Modus, es wird ein vollkommen neues Zielprojekt erzeugt.
Im Updatemodus werden grundsätzlich alle Objekte, die seit der letzten Zielprojekt-Installation im Quell-Projekt neu angelegt wurden, installiert und konfiguriert (incl. Neuverlinkung). Bestehende Objekte werden komplett und vollständig mit den Konfigurationsdaten aus dem Exportscript neu konfiguriert. Scripte werden auf Fileebene grundsätzlich gelöscht und neu geschrieben (die Script-ID im IPS Objektbaum bleibt identisch). Ausnahme: alle Objekte unterhalb einer Kategorie mit Namen „Config“ werden nicht geupdatet. Hier werden lediglich aus dem Quellprojekt kommende, neue Objekte angelegt.
Was man tun/nicht tun sollte
[ul]
[li]Keine Scripte im Zielprojekt löschen und danach updaten: Scripte werden zwar neu erstellt, Neuverlinkungen der ID’s in anderen Scripts (Objekt-Neuverlinkungen wie Events, Links etc. werden funktionieren) von und zu diesem neu angelegten Script werden fehlerhaft (wird auch als Fehler im Installationsprotokoll ausgewiesen) sein. Hier ist eine komplette Neuinstallation ratsam (Projektverzeichnis incl. aller Komponenten löschen und Export-Script erneut ausführen). Alternativ müssen diese ID’s einzeln manuell neu verlinkt werden.[/li][li]Individuelle Konfigurationen im Zielprojekt (zusätzliche Objekte, Scripte, Einstellungen) sollten nicht im Projekt selbst, sondern im speziellen „Config“-Ordner innerhalb des Projektes angelegt werden, um diese vor Updates zu schützen[/li][/ul]
Funktionsweise (Zusammenfassung)
[ul]
[li]Das Export-Script schaltet immer dann automatisch in den Update-Modus, wenn mindestens ein Installationsprotokoll als Child vom Export-Script gefunden wird[/li][li]Als Update-Basis wird immer das jüngste Installationsprotokoll unter dem Install-Script eingelesen[/li][li]Alle alten Protokollfiles (bis auf das jüngste) werden automatisch gelöscht[/li][li]Für individuelle Konfigurations-Daten kann eine „Config“-Kategorie angelegt werden: alle darin befindlichen Objekte werden beim Update nicht bearbeitet. Lediglich neue Elemente werden hinzugefügt[/li][li]Im Update-Modus wird die Konfiguration bestehender Objekte generell mit der Konfiguration aus dem Quellprojekt überschrieben (Ausnahme: Objekte in der Kategorie „Config“ werden nicht neu konfiguriert)[/li][li]Scripte werden auf File-Ebene ausgetauscht (Script-ID bleibt gleich, Ausnahme: Scripte in der Kategorie „Config“)[/li][li]Im Quellprojekt neu hinzugekommene Objekte werden im Updatemodus auch immer im Zielprojekt angelegt und konfiguriert[/li][li]Variablenprofile werden generell erneut angelegt[/li][li]WFC-Teilbaum alt wird gelöscht und neu installiert (dann immer auf Ebene 0),[/li][/ul]
Hi @ll,
pünklich zur Umstellung auf MEZ hab ich mir eine neue Version des Project Exporters ausgedacht (Download wie immer via Projektthread). Und den BETA-Status hab ich auch gleich verkauft
Auszug aus dem Changelog:
2012-10-27 V1.0
Feature
Name des Export-Scripts beinhaltet nach Installation des Zielprojektes nun auch ID des Zielprojekts ->
damit wird die zuordnung Exportscript <-> Zielprojekt einfacher, insbesondere bei Parallelinstallationen
- Update-Filterfunktion für Kategorie, Variable, Event, Link, Media entfernt
Bugfixes
WFC-Element vom Typ „Kategorie“ wurde nicht neu verlinkt
- Updatelogik für manuell benannte Script-FileNames verbessert/ergänzt
Hallo,
ich hab ein kleines Problem mit der V1.0.
Das Script erstellt klaglos das Exportscript.
Nun wollte ich das ganze testweise importieren.
Zunächst kommen Warnungen. Aber ich denke die kann man ignorieren:
Warning: Profilname darf nicht leer sein in C:\IP-Symcon2\scripts\56776.ips.php on line 260
[0] in function IPS_CreateVariableProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 260
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 261
[0] in function IPS_SetVariableProfileText in C:\IP-Symcon2\scripts\56776.ips.php on line 261
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 262
[0] in function IPS_SetVariableProfileValues in C:\IP-Symcon2\scripts\56776.ips.php on line 262
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 263
[0] in function IPS_SetVariableProfileDigits in C:\IP-Symcon2\scripts\56776.ips.php on line 263
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 264
[0] in function IPS_SetVariableProfileIcon in C:\IP-Symcon2\scripts\56776.ips.php on line 264
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 276
[0] in function IPS_SetVariableProfileAssociation in C:\IP-Symcon2\scripts\56776.ips.php on line 276
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Warning: Variablenprofil # existiert nicht in C:\IP-Symcon2\scripts\56776.ips.php on line 276
[0] in function IPS_SetVariableProfileAssociation in C:\IP-Symcon2\scripts\56776.ips.php on line 276
[1] in function createVarProfile in C:\IP-Symcon2\scripts\56776.ips.php on line 84
Dann aber bricht der Import ab:
Scriptabbruch: Script 15538.ips.php bereits im Script-Ordner vorhanden,
bereits installierte Zielprojekt-Objekte müssen manuell gelöscht werden
Er findet also mein Originalscript. Ist denke ich wegen der Updatefunktion. Aber wie kann ich dann den Import parallel installieren? Umbenennen der Originalrootkategorie hat nicht geholfen. Er hat trotzdem mein Script gefunden.
Guter Hund
cu…
Hi Marty,
die Warnungen sind vermutlich ein Bug irgendwo (IPS, PHP -> ich kann es nicht genau eingrenzen), witzigerweise kann man diese Warnmeldungen abstellen, wenn man im Exporterscript irgendwo ein Leerzeichen, Tab oder sonstwas eingibt. Ich hab paresy schon angepingt, aber noch kein Feedback.
Grundsätzlich kannst du die aber ignorieren, das hat keinen Einfluss auf das Ergebnis.
Zum 2. Punkt:
hast du evtl. noch ein Install-Log als Child unter dem Export-Script hängen? kannst du mal einen Screenshot vom Objektbaum (Export-Script, Original und Zielprojekt wenn vorhanden) einstellen?