[DISKUSSION] Diskussion zu FR: Option in Custom-Logik, die einen Eingang per Code als Parametereingang deklariert

[Robosoc]

FR aus dieser Diskussion:
viewtopic.php?f=24&t=2344

FR dient der besseren Verbreitung von Customlogiken.

Gewünscht ist eine Option, mit der per Code
A) definiert werden kann, dass ein Eingang ein Parametereingang ist und,
B) für diesen dann auch einen Defaultwert mitgibt,

so dass die Logik wie vom Ersteller gedacht und gepostet sofort funktioniert.

Zur Umsetzung: Ich denke dieser FR ist vom Ergebnis so einfach und klar, dass dies nicht durchs Forum weiter diskutiert werden sollte und dass Elabnet hier selber entscheiden kann und sollte, wie man es am einfachsten umsetzt. Es muss ja nur Abwärtkompatibel bleiben, dass soll heißen, dass alle bisher erstellten Codes weiterhin fnktionieren können müssen.

Gedankenspiele:
Ähnliche Interaktionen zwischen dem Code und der Logikzellenanzeige gibt es bereits bei den Eingangsparameter (a,c,u)...
Ich könnte mir vorstellen, dass ein optionaler fünfter Input-Parameter im Code eine gute Lösung wäre:
["Sekunde bis","Sekunde bis", "$s_to", "c", "p"]

Oder aber ein zusätzlicher, optionaler Deklarationsabschnitt

Code: Alles auswählen

Inputs: [
   ...
],
Parameterinputs: [
   
],

[Robert_Mini]

Sehr guter Vorschlag!

Ich denke es reicht:
["Sekunde bis","Sekunde bis", "$s_to","p"]

Triggeroption "p", triggert nie und setzt den Eingang als Parameter.
Der Defaultwert könnte von der Eingangsvariable kommen.

In diesem Zusammenhang stellt sich dann wieder die Frage, wann gewinnt der Code, wann die Oberfläche?

Lg
Robert

[maggyver]

Hallo,

sehr schöne Vorschläge. Jedcoch würde ich die Parameter nicht als Parameterinputs bezeichnen, auch wenn es pauschal um Inputs handelt. Wie zum Beispiel:

Code: Alles auswählen

Inputs: [
   ...
],
Parameters: [
   ...
],

Was meint Ihr dazu?


LG

René

[Matze76]

Hallo,

Ich denke dieser FR ist vom Ergebnis so einfach und klar, dass dies nicht durchs Forum weiter diskutiert werden sollte

Vielleicht hast du dich nur unglücklich ausgedrückt, aber ich finde, eine Diskussion sollte niemals von vorne herein unterbunden werden. Es wäre ja auch möglich, dass eine Mehrheit die Idee für überflüssig hält

Ich denke es reicht:
["Sekunde bis","Sekunde bis", "$s_to","p"]

Triggeroption "p", triggert nie und setzt den Eingang als Parameter.
Der Defaultwert könnte von der Eingangsvariable kommen.

Ja, denke ich auch. Ein gesonderter Deklarationsabschnitt passt für mich nicht, weil es letztendlich immer noch "Input" ist, nur eben mit anderen Default-Einstellungen ausgeprägt.

Als Nutzer möchte ich in jedem Fall weiterhin die Option haben, einen im Code per default vorgegebenen Parameter anschließend auch in eine Objektverbindung ändern zu können. Wenn ich dazu den Code ändern müsste, statt wie jetzt einfach über die Oberfläche zu gehen, wäre das für mich keine Verbesserung.

In diesem Zusammenhang stellt sich dann wieder die Frage, wann gewinnt der Code, wann die Oberfläche?

Wenn ich mir zukünftig merken müsste, wann die Oberfläche gewinnt und wann der Code, wäre das für mich ein Grund, mich gegen die Umsetzung dieses FR auszusprechen. Ich denke, dass die Code-Vorgaben hier immer nur grundlegende Default-Vorgaben sein sollten, die jederzeit durch den Nutzer über die Oberfläche übersteuert werden können. Das ist ja heute beim Input auch nicht anders. Der Nutzer, der nur die veröffentlichte Custom-Logik nutzen will sollte nicht gezwungen werden, sich mit dem Code zu beschäftigen, wenn er das nicht will.

[Robert_Mini]

In diesem Zusammenhang stellt sich dann wieder die Frage, wann gewinnt der Code, wann die Oberfläche?

Wenn ich mir zukünftig merken müsste, wann die Oberfläche gewinnt und wann der Code, wäre das für mich ein Grund, mich gegen die Umsetzung dieses FR auszusprechen. Ich denke, dass die Code-Vorgaben hier immer nur grundlegende Default-Vorgaben sein sollten, die jederzeit durch den Nutzer über die Oberfläche übersteuert werden können. Das ist ja heute beim Input auch nicht anders. Der Nutzer, der nur die veröffentlichte Custom-Logik nutzen will sollte nicht gezwungen werden, sich mit dem Code zu beschäftigen, wenn er das nicht will.

Hallo Matze!

Dieser Kommentar war darauf bezogen, dass es durchaus schwierig ist zu entscheiden, wann wer gewinnt.

Natürlich gewinnt erst mal der Code, dann die Oberfläche.
Aber was ist bei erneuten Änderungen im Code?

Hier wurde das Verhalten mit einer der letzten Versionen so angepasst, dass beim erneuten Speichern immer der Code gewinnt. Das ist zwar einerseits nachvollziehbar, oft aber auch problematisch.
Es passiert mir immer wieder mal, dass ich nach einiger Zeit im Code was anpasse/ergänze und dann übersehe, dass eine Sendeoption "ct" wieder durch "c" überschrieben wird, weil im Code noch "c" stand. Das Thema ist aber unabhängig von diesem FR. Für das Teilen von Logiken macht dieser Vorschlag absolut Sinn. Wer dann im Code was ändert, sollte eben grundlegend Bescheid wissen.

lg
Robert

[maggyver]

Hallo,

da gebe ich Robert in dieser Hinsicht recht.
Jedoch sollte die Mitgabe eines Defaultwertes optional sein.

Nehmen wir mal an der Parametereingang könnte mit einem externen Wertgeber oder Logikausgang oder Crontrigger verknüpft sein, dann gibt es für diesen Fall kein Problem (kein Defaultwert vorhanden). Es gibt auch Parameter die einfach nur beim Anlegen der Logik eingestellt werden müssen, wenn da dann ein gleich ein mitgegebener Defaultwert dran ist, umso besser. Logik ausrufen, einmal die Defaultwerte anpassen abspeichern und so oft anlegen wie notwendig. Man könnte die Defaultwerte auch als eine Art Startwert benützen. Dann lässt sich wieder die ein oder andere Lösung erschaffen.

Wer am Code etwas ändert, der sollte sich auch grundlegend darüber informiert haben.

Vielleicht sollte man darüber auch nachdenken ob man bei Customlogiken Informationen mit angezeigt werden, wenn man mit der Maus darüberfährt, wie zum Beispiel das dieser Baustein Parameterinputs hat und am Parameterinput selbst der eventuelle Defaultparameter angezeigt wird.

Wäre eine hilfreiche Funktion dann, wenn es bei solchen "Anpassungen" / "Umstellungen" / "Abspeichern" darauf ankommt.
Grundsätzlich gewinnt immer der Code.


LG

René

[Robosoc]

Vielleicht hast du dich nur unglücklich ausgedrückt, aber ich finde, eine Diskussion sollte niemals von vorne herein unterbunden werden. Es wäre ja auch möglich, dass eine Mehrheit die Idee für überflüssig hält

Jo, gebe Dir recht, war nicht glücklich. Daher habe ich das hier noch einmal zur Diskussion gewandelt. FR muss dann später folgen.

Und wie schon von Robert geschrieben, es geht nicht darum die Möglichkeiten einzuschränken, sondern lediglich im Code einer Customlogik definieren zu können, dass ein Eingang als ParameterEingang konzipiert ist. Das wäre zum Beispiel beim Verwenden von JalousieModulen Sehr hilfreich. Ich habe mir aus der Vorlage hier einen eigene für mich hilfreichen geschaffen und den 7x oder 8x im Einsatz (verschiedene Fassadenseiten, verschiedene Nutzungsarten und Reaktionen auf Sonne...) da nervt es dann sehr, wenn du jedesmal 6-7 Eingängen je Logik erklären musst, dass Sie Parametereingänge sind und dass viele die gleichen Parameter verwenden...

Und es hilft auch sehr, wenn man sich noch nicht so auskennt mit dem TWS und eine fremd-geschrieben Logik übernimmt, wenn man weis, dass ein Eingang vom Ersteller als Parameter Eingang gedacht war...

Ich finde den Vorschlag von Robert absolut perfekt und stimmig zu anderen TWS Möglichkeiten , wie SendExplicit:
["Sekunde bis","Sekunde bis", "$s_to","p"]

Ich bin mir aber unsicher ob ich das Verhalten dann auch standardmäßig wie ein u wünschen würde, wie Robert es beschrieben hat, oder eher wie ein c. Ich glaub ich fänd es tatsächlich besser, wenn ein Parameter bei Änderung im Doktormodus (und nur da kann man ihn ja live ändern) grundsätzlich die Logik auch triggert und man dann die Änderung auch gleich sieht. Zum Beispiel bei den Jalousiethemen wäre das hilfreich. Und ansonsten wäre das Verhalten ja dann wie ein u.

[Robosoc]

Jedoch sollte die Mitgabe eines Defaultwertes optional sein.

Unbedingt, ja. Ich finde sogar zwingend und nicht optional, weil das Level ja eh immer einen Defaultwert hat. Und am Liebsten sollte auch der Defaultwert aus dem Level genommen werden, der mit dem Input zusammenhängt, dann gibt es nur einen Defaultwert und der Code ändert sich nicht weiter.

[Robosoc]

Vielleicht sollte man darüber auch nachdenken ob man bei Customlogiken Informationen mit angezeigt werden, wenn man mit der Maus darüberfährt, wie zum Beispiel das dieser Baustein Parameterinputs hat und am Parameterinput selbst der eventuelle Defaultparameter angezeigt wird.

Das ist aber eine weitere Diskussion, die dann eine eigene Diskussion braucht, wenn gewünscht. Ich finde aber auch es gibt ausreichend Beschreibungsmöglichkeiten in Customlogiken, z.B. ja auch für jeden Ein- und Ausgang den MouseOverText, daher würde ich es nicht anstossen.

[Robosoc]

Nur um es nochmal sicher zu stellen und Missverständnisse zu vermeiden

Das Folgende sind normale Inputs die hier ( Siehe auch Verlinkungen im Eingangsbeitrag) nicht gemeint sind.

Nehmen wir mal an der Parametereingang könnte mit einem externen Wertgeber oder Logikausgang oder Crontrigger verknüpft sein, dann gibt es für diesen Fall kein Problem (kein Defaultwert vorhanden).

Diese Art von Eingängen sind gemeint.

Es gibt auch Parameter die einfach nur beim Anlegen der Logik eingestellt werden müssen, wenn da dann gleich ein mitgegebener Defaultwert dran ist, umso besser.