Das meinst du, aber im Ereignis wird diese Variable als Ziel vorausgewählt.
ich gehe immer auf das Ziel welches etwas machen soll und klicke dort rechts und sage Ereignis hinzufügen.
Nicht ganz woanders, es liegt halt immer unter dem Ziel. Da ich dort auch das Ereignis hinzufüge, muss ich auch nichts suchen.
Intuitive ist dort glaube ich Ansichtssache.
Ich finde es intuitive, das ich dort ein Ereignis hinzufüge wo es etwas bewirken soll.
Davon abgesehen habe ich bestimmt schon 20-30 Tage Abstinenz von der Konsole. Habe gar nicht die Zeit täglich mit IPS zu arbeiten Und ja auch ich suche viel in meinem Objektbaum, auswendig kenne ich da gar nix. Es ist nur gut gegliedert.
Michael
@Boui, so geht es mir auch. Ich stelle fest, Mensch irgendwie komisch das Ganze. Hmmm, keiner sagt was? Bin ich zu blöd?
Am besten ansprechen und daraus im besten Falle den Anstoss zu einer konstruktiven Diskussion starten.
Vermutlich wird sich aber an der speziell von mir angesprochenen Sache nichts ändern, weil sie viel zu tief im Gesamtkontext
verankert ist. Trotzdem würde ich mir wünschen das an Verbesserungen der Darstellung gearbeitet wird. Es ist halt nervig jedes
halbe oder auch alle zwei Jahr wieder in die gleiche ‚Falle‘ gelockt zu werden.
Bitte nichts für ungut, ich will niemanden etwas böses. Aber du, du gilst hier im Forum sicher als der Profi schlechthin und das völlig zurecht! Nur Anfänger und Otto Normaluser haben da ganz andere Voraussetzungen. Die Orientieren sich wie im normalen Leben.
Und da denke ich wie Boui, da betrachten wohl die meisten Menschen etwas von einem Punkt ausgehend. Man schaut von einem Punkt aus, wo will ich hin. Ich starte also immer am Ausgangspunkt. Und so würde ich das intuitiv auch bei der Vorgehensweise im IPS tun. Von der Variable wird etwas ausgelöst. Und das würde ich auch gerne so in der Darstellung im Baum wiederfinden.
Erstmal: Vielen für euer Feedback. Wenn etwas nicht intuitiv ist, schauen wir immer gerne, wie wir es verbessern können
Die Entscheidung es so zu machen wurde vor sehr sehr vielen Jahren gewählt und ist aktuell (wenn man es weiß) simpel. Immer am Ziel erstellen - dann passt alles.
Das können wir leider nicht einfach umwerfen, da es nunmal viele so gelernt haben und erwarten. Wir können leider auch nicht automatisch erkennen ob du bei einer Variable diese als Auslöser oder als Ziel nutzen willst. Beides ist ja gültig. Es wäre als irgendwie machbar einen Dialog davor zu schalten, der dich fragt, was du machen willst - ob das intuitiver ist?
Auf jeden Fall würde ich mich über Feedback freuen, wie man beide „Welten“ verbinden kann
Unabhängig von allem weiteren, einmal herzlichen Dank für das ausführliche Feedback! Genau so etwas brauchen wir und hilft uns dabei das System zu optimieren. Du hast voll und ganz recht, als Entwickler haben wir eine andere Brille auf als der Normaluser oder Einsteiger. Wir versuchen uns bei Designentscheidungen bewusst auch in diese Perspektive zu begeben, aber das funktioniert nicht immer, da wir das Produkt nun einmal sehr gut kennen.
Nun hängen die entsprechenden Eigenschaften allerdings wie du schon erkannt hast tief im Gesamtkonzept verwurzelt. Eine Anpassung ist also zum einen sehr aufwendig, zum anderen verwirrt man alle Benutzer, die es seit Jahren anders herum gewohnt sind.
Ich wollte trotzdem gerne auch einmal unsere Perspektive erörtern. Ich schreibe manche Dinge als absolut, da ich nicht jedes mal „meiner Meinung nach“ davor setzen möchte. Dennoch ist das ganze als subjektive Beschreibung gemeint. Vielleicht finden wir ja dennoch den ein oder anderen kleineren Punkt, an dem man doch noch etwas drehen kann.
Die ausgewählte Variable ist das „Ziel“ und nicht die „auslösende Variable“
Hier ist das ausgelöste Ereignis ein gewisser Sonderfall, da es ja zwei „Ziele“ hat. Eines das auslöst und eines das ausgelöst wird. Allgemein landet ein Objekt, wenn es per Kontextmenü erstellt wird unter dem angeklickten Objekt. Dies ist (meiner Meinung nach) in den meisten Fällen auch ganz erwartet. Erstelle ich eine Instanz per Rechtsklick auf eine Kategorie, dann möchte ich sie dort erstellen, etc. . Auch bei den anderen Ereignistypen, also zyklisch und Wochenplan, passt es recht deutlich, da es nun einmal nur ein „Ziel“ gibt: Das Objekt, das irgendwie geschaltet wird. Daher ist es bei der Gesamtbetrachtung passend, dass Ereignisse am Ziel hängen. Zyklische Ereignisse hätten sonst keine logische Position, da es keinen „Auslöser“ gibt und die Positionierung bei verschiedenen Typen unterschiedlich zu händeln, halte ich für sehr verwirrend.
Das Ziel kommt vor dem Aktionstyp
Das Ziel definiert die möglichen Aktionstypen. Ist das Ziel beispielsweise ein Skript, kann kein PHP Code eingetragen werden, es wird immer das Skript ausgeführt. Eine Kategorie hat wiederum keine objektspezifischen Aktionen. Darüber hinaus passt sich der Text für objektspezifische Aktionen an den Typ des Ziels an: Skripte werden ausgeführt, Variablen modifiziert, … Durch diese Abhängigkeit passt es, dass zuerst das Ziel gewählt wird und in Abhängigkeit davon der Aktionstyp. Das Template, welches beim Wechsel auf PHP Code eingetragen wird entspricht übrigens der vorher ausgewählten Aktion, also am Beispiel deiner Bilder „Auf Wert setzen“ mit einem leeren String.
Das Ziel bleibt bestehen obwohl mein Skript gar nichts damit zu tun hat
Eine Aktion ist so gedacht, dass sie sich auf das darunterliegende Objekt, also das Ziel, auswirkt. Dies wirst du bei allen vordefinierten Aktionen auch so wiederfinden. Ich vermute auch, dass dies bei den meisten PHP-Code-Aktionen so verwendet wird. Wenn du das hier anders löst, dann passt die Bezeichnung des Ziels tatsächlich nicht mehr, aber es ist leider nicht möglich den Code auszuwerten ob er sich auf das Objekt bezieht. In deinem Sonderfall würde tatsächlich die Bezeichnung „Position“ besser passen, dies ist im allgemeinen aber nicht der Fall. Und da der Sonderfall nicht detektiert werden kann, ist es nicht möglich hier intelligent dazwischen zu gehen.
Es sollte bei String-Variablen „Inhalt“ heißen und nicht „Wert“
Dies sehe ich nicht so. Auch der Text in einer String-Variablen ist ein Wert. Hier mag noch die Informatikerbrille dazu kommen, aber ich sehe hier keinen Mehrwert oder erhöhtes Verständnis, wenn man auf einmal mit zwei Begriffen jongliert.
Und auch noch einmal abschließend: Auch wenn ich hier eigentlich nur ausführlich geschrieben habe, warum wir deine Vorschläge nicht umsetzen, freue ich mich immer sehr über ausführliches Feedback. Ich rechne es dir hoch an, dass du dir die Zeit genommen hast, deine Perspektive ausführlich und präzise zu erörtern. Vielen Dank dafür!
Das können wir leider nicht einfach umwerfen, da es nunmal viele so gelernt haben und erwarten. Wir können leider auch nicht automatisch erkennen ob du bei einer Variable diese als Auslöser oder als Ziel nutzen willst.
Das hatte ich mir schon so gedacht. Es würde sicher ein Massen Waldsterben an IPS Bäumen geben, würdet ihr da etwas ändern
Wobei ich meine ihr habt doch schon die halbe Lösung parat. In den anderen Objekte gibt es doch das Feld ‚Ort‘. Im Ereignis müsste also zusätzlich genau das Feld Ort (Die Position im Baum) zusätzlich eingeführt werden um dann die Bedeutung von ‚Ziel‘ tatsächlich auch darauf zu beschränken, ein Ziel für ein Ereignis anzuzeigen.
Das könntet ihr im ersten Schritt ja erst einmal heimlich unsichtbar unterhalb des Radars tun. Wenn das dann sicher läuft, könntet ihr im zweiten Schritt das neue Feld aktiv und sichtbar schalten und das Kontext Menü noch folgendermaßen erweitern:
Letzteres entspräche dann dem bisherigen Kontextmenüeintrag. ‚Ort‘ und ‚Ziel‘ wären gleich und der ‚Ort‘ könnte ggf. sogar gegen Veränderung gesperrt werden. = Alte Funktionalität.
Bei dem Menüpunkt ’ Ereignis (Unter Quellobjekt)’ würde in dem Ort, die ursprünglich selektierte Variable stehen, ebenso wie im Feld ‚Auslösende Variable‘. Das ‚Ziel‘ kann dann, wenn es denn tatsächlich eins gibt! selektiert werden. Bei PHP Code ausführen, gibt es ja vielleicht ja gar ken Ziel! Dort könnten ja eine X beliebige Anzahl von Variablen angesprochen, oder Scripte ausgeführt werden…
Hallo Leute,
die Diskussion ist ja aus meiner Sicht ordentlich zu Ende geführt und trotzdem möchte ich meinen Senf dazu geben, bevor es nachher in eine Richtung läuft die mir nicht gefällt und ich habe mich „gewehrt“.
Ich bin „normaler“ User, trotzdem „hängen“ alle Ereignisse am Ziel! Bei mir hängen die Ereignisse sogar fast nur an Scripten, an Variablen vielleicht 4-5 und ich habe mehr als 3000 davon.
Ich kann den Gedanken verstehen ein Ereignis vom Auslöser aus zu sehen. Bei mir gibt es reichlich Ziele, die viele Ereignisse(teilweise sogar 10 oder mehr) zugeordnet haben. Wenn diese nicht am Ziel hängen würden gäbe es eine gewaltige Sucherei wer meine Variable/Script auslöst.
Und wenn ich mal sehen will, ob was ein Ereignis auslöst, dann kann ich nach Referenzen suchen.
@Dr. Niels und @Paresy - Solltet ihr irgendwann doch auf das schmale Brett kommen, dann bitte als Schalter im Gesamtsystem, wo dann der User wählen kann -Auslöser oder Ziel - generelle Auswahl. Bitte nicht jedesmal Abfragen, das würde Nerven.
Moin,
hier möchte ich mich den Worten von Axel mal anschliessen. Genauso sehe ich das auch.
Wobei auch ich die Diskussion mit Interesse gelesen habe und sie richtig gut fand. Bei meinen letzten Neukunden/usern treten genau diese (für mich) Verständnisprobleme auf, auch die Doku ist da an vielen Stellen doch mehr für den „Techniker“ geeignet. Nur habe ich als „Techniker“ (und langjähriger User) auch leider keine Idee wie man das dann wirklich besser machen kann.
Man könnte, so als Vorschlag, vielleicht den Dialog in der Konsole anpassen. So das oben zuerst das Ziel steht, welches ja auch durch die Auswahl im Objektbaum vorgelegt wird.
Ebenso ist in der Doku der erste Absatz etwas zu unpräzise was hier mit untergeordnet gemeint ist.
Michael
@Dr.Niels
Was habe ich? -> Eine Variable mit einem automatisch generierten Action Script:
Was möchte ich? -> Ein zyklisches Ereignis, das einmal pro Minute das automatisch generierte Action Script aufruft.
Was tue ich? -> Action Script selektieren -> Zyklisches Ereignis auswählen -> und folgende Einstellungen ausführen:
Ich würde gerne noch etwas ansprechen, dass in die Kategorie ‚Das ist schon seit Urzeiten so‘ fällt.
Immerhin ist die Web Console ein neues Produkt und sollte daher vielleicht auch die Chance bieten
alte Zöpfe abzuschneiden. Natürlich ist mir bewußt wie konträr so etwas gesehen werden kann. Und
auch, dass im Hintergrund unter Umständen alte Codebestände vorhanden sind, die wirklich problemlos
seit Jahren laufen. Wer möchte sowas schon gerne ändern? Kaum einer, das verstehe ich schon,
aber ansprechen möchte ich es dennoch.
Es geht um das anlegen und um die Darstellung eines zyklischen Ereignisses.
Beispiel:
Was möchte ich tun? -> Ich möchte das ein Script einmal pro Minute ausgeführt wird.
Was ich mich dabei immer Frage, warum muss ich ein Tagesmuster auswählen, wenn ich doch nur ein Zeitmuster benötige?
Das gleiche gilt natürlich auch umgekehrt.
Könnte man nicht die beiden Muster durch Schiebeschalter in dem Einrichtungs Popup einzeln aktivierbar machen?
Ein Muster muss dann mindestens aktiviert werden. Und ein nicht aktiviertes wird intern mit Default Werten belegt, wie jetzt auch schon.
Was mir dabei vor allem ins Auge sticht ist die Anzeige in der Console: (Siehe Consolen Screenshot)
Ereignis: Alle 1 Tag(e), alle 1 Minute(n)
Erfahrene User übersehen so etwas geflissentlich. Aber Anfänger, die kratzen sich ne kahle Stelle auf dem Kopf…
Vielleicht besteht ja die Chance das zu ändern!?
@Gollum: Mittlerweile sollte IP-Symcon in den zyklischen Dialogen prüfen, ob du eine „Von“ und eine „Bis“ Zeit eingetragen hast. Diese sollten auch je mit 0:00 Uhr initialisiert sein. Ich vermute, du bist noch auf einer älteren Version unterwegs? Oder hast du einen Bug entdeckt?
Über den zyklischen Dialog haben wir auch schon nachgedacht. Eine Überlegung war es, eine vereinfachte Version anzubieten, welche in der Bedienung verständlicher ist, aber halt nicht den vollen Umfang bietet. Diese kann dann aber durch Klick auf „Experteneinstellungen“ oder dergleichen aufs bekannte volle Programm erweitert werden. Das ist aber noch in keiner Weise ausgearbeitet. Aber was haltet ihr davon? Was wären für euch geeignete grundlegende Einstellungen?
Zur ersten Frage: IP-Symcon 5.3, Docker, 16.03.2020, 586b5fea851a
Der Fehler aus dem Post 148 tritt auf, wenn man ein zyklisches Ereignis anlegt, dabei das Tagesmuster unverändert läßt und das Zeitmuster auf z.B. minütlich ändert. Dann die Minuten auf größer 0 ändern, denn sonst erfolgt tatsächlich eine entsprechende Meldung. Und dann die beiden 00:00.00 Zeiten mit dem daneben positioniertem X löschen. Dann das Ganze mit ‚OK‘ speichern.
Folge: Die Meldung aus dem Post 148 erscheint, obwohl ein Ereignis angelegt wurde. Und auch aktiv ist.
Zur zweiten Frage:
Meiner Meinung nach sollte die Möglichkeit bestehen, auswählen zu können ob man ein Tagesmuster oder ein Zeitmuster oder eine Kombination aus beiden wünscht. Wenn dann noch eine entsprechende Ausgabe in der Console erfolgt, wäre das schon alles.
Wobei, heute wird der Tag immer mit 1 und die Minuten mit 0 initialisiert. Zukünftig könnte das ausgwählte Muster entsprechend mit 1 initialisiert werden.
Noch eine Sache. Wenn man ganz pedantisch wäre, könnte man sicher auch die von, bis Zeiten monieren.
Von 00:00:00 bis 00:00:00 wäre aus meiner Sicht maximal genau eine Sekunde. Wobei ihr sicher einen 24 Stunden Zeitraum damit beschreiben wollt.Korrekter wäre vermutlich die folgende Darstellung. 00:00:00 23:59:59 (Wobei ich nicht weiß, ob das international vielleicht anders gesehen wird!?)
@An alle
Bitte teilt Dr.Niels eure Meinung zu seiner zweiten Frage mit
Und ja auch ich suche viel in meinem Objektbaum, auswendig kenne ich da gar nix. Es ist nur gut gegliedert.
